This content originally appeared on Bits and Pieces - Medium and was authored by Siddhesh Shinde
Types of Frontend Applications: Micro-frontends, Single page applications (SPAs), Isomorphic applications, Static page websites, & Jamstack.
I’ve recently read the book Building Micro-frontend and I’ve decided to share some of the key points I’ve learned from Chapter 1: The Frontend Landscape with you all.
Micro-frontend Application
It is an emerging architecture inspired by microservices architecture.
The main idea is to break down a monolithic codebase into smaller parts, allowing the organization to spread the work among teams.
In the micro-frontend application, the business logic and code complexity are reduced drastically but the overhead on automation, governance, observability, and communication have to be considered.
Teams and organizations are structured according to our desired architecture and not vice versa.
Micro-frontends combined with microservices and a strong engineering culture but we can also combine it with any Backend architecture such as a monolith Backend or service-oriented architecture(SOA).
💡 Microfrontends are easier when you can apply a component-driven development approach to them. And this is exactly the approach Bit enables.
Bit provides an integrated dev environment (compiler, tester, linter, documentation, CI, dev server, and packaging/dependency management/bundler all-in-one) for building apps with React or Angular. It enables you to quickly set up a dev environment that follows the best practices implemented by the framework of your choice. Learn more here and here. Read the documentation to find out how you can use Bit with React and Angular.
Single page Application(SPA)
It consists of a single or few JS files that encapsulate the entire FE application.
The client downloads the entire application code just once, at the beginning of its life cycle, and the entire application logic is then available up front for the entire user’s session. In SPA when we click on some button it does not reload the whole page but the part of the page is rendered because of that we can jump from one part of the application to another without waiting too long.
SPA also allows you to decide how we are going to split the application logic between server and client.
Fat client with thin server ⇒ client mainly stores the logic.
- When we are using a desktop application where storing some data offline was essential then use this type of SPA.
Thin server with fat client ⇒ server mainly stores the logic.
For SEO it is hard to understand how to navigate Single page website or application, it won’t have an easy job indexing all the contents served by a SPA unless we prepare an alternative way for fetching it.
Downloading all the applications in one go can have a disadvantage as it leads to memory leakage when a user is jumping from one view to another and when we try to download with an unstable or unreliable connection it makes the user experience very bad.
The application will not run smoothly when the device that loads the SPA doesn’t have great hardware.
It is very hard for an organization with a big team to work on the same codebase as it will lead to a mix of approaches and decisions that could confuse many team members.
Isomorphic applications
Isomorphic or universal applications are web applications where the code between server and client is shared and can run in both contexts.
It is beneficial for time to interact, A/B testing, and SEO.
- SEO ⇒ In an isomorphic application page is rendered from the server side without the need for additional server requests. When served it provides the crawler with an HTML page with all the information inside ready to be indexed immediately without an additional round trip to the server.
- A/B testing ⇒ we can integrate A/B testing platforms nicely without much effort. A/B testing is the act of running a simultaneous experiment between two or more variants of a page to see which one performs the best.
The server does all the heavy work like rendering, retrieving data, and generating the view in order to serve the client a page that does not need additional round trips for requesting data to display.
In isomorphic applications, we also use a hybrid approach. We render part of the page on the server side to improve the time to interact and then lazy-load additional javascript files for the benefit of both the isomorphic application and SPA. We decide how much code is shared in Backend based on the project requirement.
Routing is also an interesting part of an isomorphic application because we can decide to manage it on the server side, only serving a status page any time the user interacts with a link on the client.
An isomorphic application could suffer from a scalability problem if a project is really successful and visited by millions of users. Because we are creating an HTML page pre-rendered on the server, we will need to create the right caching strategy to minimize the impact on the server.
Organization wise Isomorphic applications suffer similar problems as a SPA.
Static page Website
- In this, every time users click on a link, they are loading a new static page. It is an old-school method.
- It is still in use for a quick website that is meant to be online for a short period of time.
- In the last few years, this type of website has mutated into a single page that expands vertically instead of loading different pages.
- Some of these websites also lazy load the content, waiting until the user scrolls to a specific position to load content.
- The investment on the technical side is fairly low.
Jamstack
- New frontend architecture (JavaScript, APIs, and markup).
- It is a modern architecture to help create fast and secure sites and dynamic apps with JavaScript/API and pre-rendered markup served without a web server.
- Its output is a status artifact composed of HTML, CSS, and Javascript. And this a directly served by CDN since the application doesn’t require any server-side technology to work.
- The advantage of this architecture is better performance, cheaper infrastructure and maintenance, higher security due to the decrease of the attack surface, and easy integration with headless CMS.
Conclusion
Micro-frontend, Single Page Application (SPA), Isomorphic, Static page Websites and Jamstack are the most commonly use frontend architecture. Each of them comes with advantages and disadvantages, so choose which ones will be beneficial for your project.
Build Microfrontends with reusable components
Bit’s open-source tool help 250,000+ devs to build apps with components.
Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.
Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:
→ Micro-Frontends
→ Design System
→ Code-Sharing and reuse
→ Monorepo
Learn more:
- How We Build Micro Frontends
- How we Build a Component Design System
- How to reuse React components across your projects
- 5 Ways to Build a React Monorepo
- How to Create a Composable React App with Bit
The Frontend Landscape: Different Types of Frontend Applications was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Siddhesh Shinde
Siddhesh Shinde | Sciencx (2023-03-16T12:40:11+00:00) The Frontend Landscape: Different Types of Frontend Applications. Retrieved from https://www.scien.cx/2023/03/16/the-frontend-landscape-different-types-of-frontend-applications/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.