I'm new to microservices. In my project we're trying to break a monolith application into smaller microservices.
It is fairly easy to implement backend systems with polyglot technology. Is the same achievable for frontend?
BFF (backend for frontend) seems to be a popular pattern to implement frontend in microservices. However, doesn't it result in frontend monoliths? Maybe my understanding of BFF is partial/incorrect.
There are few options such as SSI (server side includes) & ESI (Edge side includes) that could help in achieving polyglot in frontend.
But wasn't portlet technology trying to achieve something similar in early 2000's?
ESI is in trial stage at thoughtworks technology radar (link).
Do you think this is the right direction. Any advice will be appreciated.
I would like to clarify few point in this context.
Microservices does not mandate Polyglot technology, it just gives you the flexibility.
Frond end design should follow your application needs and if your functional & non-functional requirements have a strong business case for using Polyglot technology for front-end you can. But microservices does not enforce anything.
Decision to choose ESI, BFF, SSI, Portlet etc. should be made purely based on your application and features fitment in to particular pattern.
Related
I wanted to start a full stack project, with all the tech stacks in the market i am confused to which one should i pick. I know reactjs in frontend, nodejs and a little bit of django in backend.
First should i use Reactjs or any other frontend framework which is a single page application so all the JS code will execute from frontend or should i use that or Nextjs which does the server side rendering so in the browser we reduce the execution of js. If i stick with Nextjs then suppose i wanted to create a mobile app for my project can i use the nextjs for that or should i shift the code entirely
2)Does backend language really matter, if matters which language should i use and If it doesn’t matter then in nodejs which server framework should i pick(ex: expressjs)
Should I go with server or serverless while creating the api then it does not matter with the framework(because lately I have seen many realtime apps backend code is entirely wrriten by serverless functions using cloud)
4)tell me some of the important things i should use in a realtime app like docker, Kubernetes, load balancer, and any other things you might think this should be present in the full stack app
if you know any blogs or articles about choosing the architecture for ur project comment down.
This is a very opinion and experience based question that cannot be answered as you are asking it (and is technically out of scope in stackoverflow). I will try to help as much as possible anyway.
In general many different stacks are viable and in order to be productive it is more important that you are experienced in what you decide to use. This is because most technologies have pitfalls that can only be avoided by knowing them / experience.
Besides the frontend technologies/frameworks you listed there are many others. Having some experience with React-Native as well, my personal current favorites would be Angular and Flutter (both Google technologies) for web/apps.
It does and it doesn't matter. Without knowing your specific requirements no recommendation can be given though. As a general hint I recommend to use a language that your developers love - There is usually a reason for it. See the 2021 Stackoverflow Developer Survey.
Server vs. Serverless is mostly a business decision and you have to model your costs including hosting / development / maintenance efforts vs. usage models. Another aspect in this decision is time-to-market pressure since Serverless may be a bit faster to finish in some scenarios.
This cannot be answered without knowing the details and requirements of your project. Recommendations could be from hosting a static single web page in a S3 bucket to running your own fleet of (cloud-)-bare-metal clusters or buying a supercomputer.
Micro-frontend is a microservice approach to frontend web development.
Microservice is an architectural style that structures an application as a collection of small autonomous services, modeled around a business domain.
But
What are the main differences beetween micro-frontend and microservices?.
Microservices are related to back-end side functionalities while
Microfrontends is related to the frontend & the idea is to divide your application on the client side.
This division is especially helpful when you have a group of many developers working over the same product/codebase.
Take a look at the below links for understanding the difference, the idea of micro-frontends & their pros and cons.
https://www.youtube.com/watch?v=BuRB3djraeM
https://www.youtube.com/watch?v=Bnmy5zMY14s
https://www.youtube.com/watch?v=asqgKaUMXq0
Just naming. Microfrontend is client version of microservices. You can implement your frontend as multiple applications (microfrontends). On backend side you create multiple deployables (microservices) to build an application. Of course, there are some patterns and best practices (API Gateway, Service Discovery etc.) for microservices and microfrontends which may not be applicable to one or differ between each other. However the main idea is same.
In theory I understand how Microservices work and why they can be helpful in various cases but I still don´t get how it works in practice.
Let´s say there´s an online shop based on a CMS as a monolith application.
And there´s now the need to run the online shop in a MIcroservices architecture.
How would this Microservices architecture differ technically from the current, monolith, architecture?
For example, I pick out the productsearch.php. If i want to scale this function, normally I had to set up a new server and copy the whole CMS ressources folder to it for loadbalancing.
And with Microservices, productsearch.php would be a single Microservice I guess, and I would have to just copy this php file to scale without the need to copy other ressources?
I have tried to explain it using this diagram of a fictitious CMS. With micro services architecture, we can independently scale each micro service. Each micro service may be developed by a different team, they may be even developed using different technology. But we great flexibility comes great maintenance overhead, I believe it is worth it as most of it can be automated.
Put simply, each module in a molithic application is a potential candidate for microservice. Howerver, microservices can be more granular than a traditional module.
This provides a good job at explaining how to decompose your monolithic application. http://microservices.io/patterns/decomposition/decompose-by-business-capability.html
Technically and conceptually, a microservice is independent of other services (where in a monolith you'd have modules with inter-dependencies).
Technically, a microservice built on modern microservices platforms (such as Node.JS, Spring Boot or .NetCore) will be more easily able to take advantages of containerization systems (such as Docker), perhaps supported by service registry and configuration management technologies (such as Kubernetes, ZooKeeper, Eureka and so on).
The advantage of containerization is that it'll be easier to scale-out (add more containers). Going further, the whole microservice / containerization concepts, and related technologies, also help enable things like CI/CD.
My company is big on sharepoint. but server side controls have inherent problem with performance. I want to move page rendering responsibility to client side with concept similar to SPA. what is best framework or architectural style for this.
Single Page Applications are gaining immense popularity these days mainly because of their fluidity and responsiveness. Clearly the framework and architectural style depends heavily upon the requirements.
Framework:-
There are host of frameworks available that can be leveraged depending upon the complexity of the SPA you are planning - Backbone, Angular, Knockout, Ember etc. I personally prefer Angular and Knockout frameworks because of their simplicity and data binding and directive capabilities. Moreover you can also efficiently handle REST calls to SharePoint using Breeze.js. Refer to this link for more details.
Architecture Styles:-
Typically SPAs use MVC or MVVM patterns to decouple the UI aspect from the business logic, but this again is requirement driven. Regardless of the style/pattern it is important to keep the code modular and no to expose implementation details as much as possible.
Packaging:-
As far as SPAs for SharePoint are concerned, the best way to package and deploy them is in the form of SharePoint Hosted Apps. SharePoint Hosted Apps only allow client side code and hence leveraging Javascript object model and REST API for SharePoint making them ideal for deployment of SPA over SharePoint.
References:-
https://www.pluralsight.com/courses/building-sharepoint-apps-spa-angularjs
This is quite a debate we have at the moment between colleagues and I'm looking for fresh news ideas or suggestions. Where better than StackOverflow to ask!
We have web developers and back-end developers (PHP for Drupal or JSP for other platforms) and we used to develop a working static HTML/CSS/JS prototype and handed it to back-end developers to integrate.
However, we end up having issues where they have to split the static prototype to fit their different JSP/PHP pages and some bugs surfaces. We then have to double check their integration and squash the bugs.
I'm wondering if there's a way to create, deconstruct the static prototype to be easier to integrate for back-end developers? Maybe a way to split files and use SHTML includes to map the back-end? I'm just throwing ideas...
What do you think?
The terms web developer and backend developer are not clearly defined. This is partly due, in my opinion, to the templating technologies used (PHP, JSP, etc.) which encourage this problem. We talk of front-end and back-end developers but don't consider front-end and back-end applications.
I'm wondering if there's a way to create, deconstruct the static
prototype to be easier to integrate for back-end developers?
Why?
I think the better solution is to have back-end developers be just that, back-end developers. Why are you giving a presentation template to a back-end developer (I know, it's because you're using a templating technology such as PHP, JSP, etc.)?
If you really want to fix this problem you've got to separate these rolls by ditching the templating technologies and adopt a RESTful approach. Allow your back-end developers to only develop server-side code. Allow your front-end developers to only develop client-side code. Let the user interface designers provide a static prototype to the client developer who will make rest api calls to get the data needed to populate the static prototype. Then the back-end developer won't ever have to touch a piece of the client-side presentation.
Doing this will allow you to have multiple clients (web, mobile, etc.) using the same RESTful services.
See this SO Question/Answer for more on RESTful web services.