The hyped, happening and happened front end frameworks and web APIs @ bol.com (Part 3)
We asked 25 developers, five tech leads and someone “who does unspeakable things with technology” - more commonly known as our principle tech lead which technologies (tools, libraries, language or frameworks) they believe are hyped, happening or happened:
- hyped - which new technologies are you eager to learn more about this year?
- happening - are there any exciting technologies you used last year that we should learn this year?
- happened - did you walk away from any technologies last year?
This is what we got back:
This blog post, which is part of a series of six blog posts in total, we have a closer look at front end frameworks and web APIs:
Here you can find a complete overview of all blogs in this series.
Front end frameworks
User experience and user interaction are key components for any online business. So it is crucial to pick a good front end framework that gives your users a seamless experience, and at the same time makes it easier for developers to work with and maintain.
- Virtual DOM - a version of the actual DOM for UI rendering. It is very efficient and components load quickly by making minimal changes to the real DOM.
- Isolated components - allows reusability of isolated components in other parts of the application since react components are encapsulated.
- Functional programming - react works with functional programming concepts such as immutable data and declarative style of programming. This makes react code easy to maintain, test and reuse.
- Steep learning curve - since react introduces JSX which combines HTML with JS, it can be confusing to new developers.
- Lack of documentation - documentation is not updated frequently due to its high growth of features, making it hard to find certain detailed information.
- Out of the box functionality - the default setup of Angular gives developers everything they need to set up a complete web app, which reduces the need for third party libraries.
- Reusability - Angular has a component based architecture which allows reusability of the UI parts. Angular’s dependency injection feature makes these dependencies easy to manage.
- No legacy support - since Angular has no backwards compatibility with AngularJS, and there are a lot of differences between the two, migrating legacy apps is not easy.
- Complexity - there is a steep learning curve since Angular can be overwhelming with its features. It can be difficult to understand the multilayer architecture and to manage components.
Vue is a relatively lightweight and simple framework compared to ReactJS and Angular. Vue uses a virtual DOM similar to React and two way data binding like Angular. Since it is a simple framework, it is relatively easy to set up a web app with it.
- Clear and simple - Vue is quite easy to pick up and to build apps with and allows flexibility in its implementation. You can also easily integrate it into separate systems.
- Improved performance - the framework is only around 18KB in size, making it very lightweight and improves loading time in the front end.
- Community - the Vue community is relatively small so finding support can be difficult.
- Too much flexibility - there are too many ways you can implement a functionality, which might lead to irregular implementations in the codebase.
A common strategy which companies adopt is to create a separate web application and a mobile application. This costs almost twice the development time and effort. Flutter is a Google UI toolkit which supports cross-platform development which allows developers to build native apps for desktop, Android and iOS from a single code base! It combines the advantage of a native app with a consistent UI across all platforms.
- Single UI and business logic - Flutter adopts a code once, run anywhere approach. This reduces the time to market since a Flutter app can work on any platform.
- Reduced coding time - Flutter provides a wide range of widgets, which are ready to use and highly customizable.
- Native performance - Flutter’s method of rendering makes the application look and perform native on every platform. It does so by building the app directly in the machine code.
- Experimental tooling - since Flutter is relatively new, many functionalities and tools are in the alpha testing phase which means that it can still contain bugs.
- Huge file size - Flutter is quite big in size, around 4MB which can slow down the applications.
If you are a backend developer, chances are that you don’t want to learn a front end language. Fret no more, since Vaadin comes to the rescue - Vaadin is a front end framework which Java developers can use! It’s features include:
- Component based architecture allows reusability of UI blocks.
- Drag and drop UI functionality is also provided in addition, which makes designing UI a bit easier.
- Add on components are provided such as components for data visualization, adjusting themes, etc.
- Increasing security by keeping user interface logic in the server.
We used Vaadin extensively for building business applications that are used by a select group of internal users. We never used it for large customer-facing web applications. In fact, "Vaadin was never built for massive public-facing web sites. If you need facebook-level scalability Vaadin isn’t the best tool for that. But for anything less, Vaadin demonstrably works, and works well." (Reference blog) Latest trend is that we are replacing Vaadin with the technology we use for building somewhat larger web applications that external users (think of external sellers) use - Angular.
In many cases services that you did not develop will call your microservice. With that said, clearly defining your API becomes key.
Enter OpenAPI - a framework for describing your API in a language-agnostic way. The main idea is to create a specification for a REST API using a yaml file that also, for example, product owners and business analysts can understand.
I’m sure by now you’ve heard of the term ‘API driven development (ADD)’. This is where OpenAPI really comes in handy. But first let’s define what this actually means. It means that you design the definition of the API first before starting on any other lifecycle operation. That is, you first define the API’s interface - detailing the requests and responses for the service endpoints. Only after that we start implementing and testing the business logic (in whatever language).
This has several advantages such as:
- We can check the specification with the client whether the API matches their requirements. This allows us to make changes efficiently, preventing us from changing business logic later on.
- Most services need to define a domain model (in a programming language) which matches the model defined in the API specification. Usually this will be a cumbersome task, but with the OpenAPI generator tool, we can easily automate this! It allows us to create server stubs in the language of our choice, and it automatically updates the domain models in case the model defined in the specification changes.
- ADD allows parallel development by the front end and back end teams since the specification serves as a contract for what to expect, i.e. for an endpoint - the data it consumes and the data it responds with. This allows teams to work independently and saves a lot of time.
When REST was initially released and adopted, applications were quite simple and REST did the job. But when we look at the applications we build now, things became a lot more complicated which leads to the following issues:
- REST has a fixed API which returns a fixed data structure. This works with a few clients. With more clients, building an API serving everyone’s needs becomes cumbersome and leads to an exhaustive list of endpoints.
- If a client requests a change in the data returned by an API, the server side has to be updated first.
GraphQL intends to solve these issues by creating a single endpoint receiving and returning information, rather than defining multiple endpoints like it's done in REST. At its core, GraphQL is a language for querying databases from a client application. This gives clients the ability to request exactly what they need from the server, and receive exactly that data. Nothing more, nothing less.
GraphQL achieves this by providing the client with a schema which is basically a model of the underlying data that can be requested. This schema decides what queries can be made and what kind of data can be fetched, along with the relationship between the different data types.
Having said that, it also has some pitfalls:
- GraphQL is best utilized for complex services which have a large number of clients with different needs.
- In most cases, it returns a 200 status code even if the data is not present, making troubleshooting difficult since you need to inspect the response payload to find out where the issue is.
- It is much more complicated to implement caching in GraphQL since there are a lot of possible query combinations. In REST, there are specific endpoints defined for resources which we can cache based on the URL.
Want to read more about hyped, happening and happened tech at bol.com? Go back to The hyped, happening and happened tech @ bol.com for a complete overview of all the hyped, happening and happened tech at bol.com.