What Goes Into a Modern Frontend Developer’s Tech-stack?
Being in the frontend development industry can be both overwhelming and exciting at the same time. The constant change and continuous improvements around frameworks, languages, and architecture concepts have made frontend developer’s jobs more challenging and have given it a wider range of possibilities when choosing the tech-stack. This is my story about how we’ve chosen the frontend tech-stack in a big industrial company like Grundfos.
Research phase
A huge part of being a developer, both in the frontend as well as in the backend, is trying to keep up with the latest trends and follow the technological development. This can be done by reading up tech blogs, watching tutorials, joining tech conferences, or workshops, so mostly by being curious and active.
It’s not enough to just know what’s trendy and burn for it, it’s also important to be able to assess and put together a tech-stack that would be suitable for your specific use-case, and would fit the business requirements. At Grundfos, we call that the research phase, and we do it before starting a project, for establishing the foundation on which the rest will be built on. We try to focus on this phase and invest the necessary time to figure out what framework would be a good match for a project, or what library fits which features. This is usually done by experimenting with different potential solutions, getting inspired by others that have done something similar, brainstorming with the team, and finally putting together the findings. The result would most commonly be a basic implementation of certain technologies (proof of concept — POC). Based on this, developers would evaluate and decide to either go for it or research more. This is the most exciting part, at least for me, because you get to learn a lot, collaborate with others, and put a real footprint on the project from the very beginning.
Technical choices over time
The final product, that the end-user gets to interact with, hides a lot of “behind the scene”, work that is split between frontend/backend/connectivity/hardware and put together as a whole end-to-end solution. Being a part of building digital offerings at Grundfos, I got to try different frameworks/libraries and to be part of both researching and developing. Back in 2017, when I joined Grundfos, I was assigned to my first project where the tech-stack was already decided, but I was quite happy about It. It was React and Redux for building the user interface, Typescript as programing language and REST for data fetching. I’ll go into more detail about each of the technologies a bit later. We managed quite well with the chosen stack, for about a year or so, during that period, we were building a basic monitoring solution, to replace some part of an older system. However, by using Redux we started to have too much boilerplate code for achieving basic interactions, like dispatching actions when initializing a request and handling the response afterward. Luckily React introduced hooks and a new context API, that was simpler and faster, which made Redux even less relevant. When we moved to a new project, we continued to use REST endpoints for data communication. However as the features became more complex, and the requirements often changed, we ended up with too much unnecessary data and too many endpoints to fetch. Here is when we moved our focus on GraphQL, and for the next project we switched to it completely.
Current project
The current project I’m working on is called Grundfos iCloud monitoring (GiM in short). This is a mix of new hardware, with embedded condition monitoring functionalities plus some cloud services, for handling remote monitoring and real-time interaction with the hardware. The web solution will primarily give users an overview of their devices’ data through different visualizations like graphs and tables. It will also keep the users updated with the status of their devices through notifications, plus maintain an event log with historical data. The main goals of the web interface are to offer the users a solution that is intuitive, fast, and easy to navigate. To fulfill these “simple” 😊 goals, we’ve settled on a new tech-stack. Below I’ll list some of the main technologies we use and the thoughts behind choosing them.
The stack
Frontend library — React is a declarative, efficient, and flexible open-source JavaScript library for building interactive user interfaces. Initially released in March 2013, React was developed and maintained by Facebook, and one of its main beauties is that it lets you compose complex UIs from small and isolated pieces called “components” (Reactjs, u.d.)
Why React?
The main purpose of React is to be fast, scalable, and simple, and these are also the main reasons why we’ve chosen it. By using the virtual DOM, React solves the issue of updating the DOM which is the biggest problem when it comes to web performance. The component-based structure is particularly useful when building a large web application because you get to build once and reuse afterward which makes it easy to maintain and do changes. Finally, React has strong community support, which means there are many developers around the world working on making it even better.
Programming language — Typescript is an open-source programming language developed and maintained by Microsoft. It’s a superset of JavaScript and it primarily provides optional static types, classes, and interfaces on top of JavaScript (TypeScript, u.d.). It’s especially a strong tool for large applications, because it allows you to write robust code, and let you spot errors much faster and earlier in the process.
Why Typescript
One of the major reasons, for us to choose Typescript is that it provides a better code-readability. Basically you can quickly understand what is what, meaning what arguments does a function accept, what value does it return, and what external data does it require. Having all this knowledge makes it much simpler to work in each other’s code or to refactor, without having to bother your colleague or risking to introduce bugs Some of the disadvantages though, is that third-party libraries don’t always provide a type definition file, which is really a must when using Typescript.
Data fetching
In a few words, data fetching means sending an HTTP request to a service and receiving some response, i.e. calling some functions over a network. Data visualization is a crucial part of building a good User Interface as this is what the end-user will see and act on when accessing the UI.
GraphQL is an open-source data query and manipulation language for APIs. It started as an internal research project at Facebook but it grew into a new standard for API development (GraphQL, u.d.). A GraphQL API consists of schema that describes the data types used in the API, resolvers that are attached functions to each field in the schema and queries/mutations that allows performing common CRUD operations on the data.
Why GraphQL
Coming from a quite complex REST setup, the main reason for switching to GraphQL, was to get away from having to deal with lots of properties and mappings, and be able to ask for exactly what is needed and only receive that from the API. GraphQL queries usually contain data from multiple resources, which means multiple requests behind the scene, but from the frontend, there is only one call and no multiple round-trips. However, it’s worth mentioning that the debugging experience it’s not very straightforward, as you’d only have one POST request in the browser and that would always return an HTTP status code of 200 regardless of whether or not that query was successful.
Conclusion
As mentioned in the beginning, the frontend development world is in constant change and new frameworks/libraries pop up all the time. So there is no right or wrong tech-stack, as long as it fits the purpose and gives a good developer experience. We’ll probably stick to ours for a while, as we’ve put lots of thoughts into it, and because it does meet our current business requirements. However, if something new and worth looking at comes in, we might consider giving it a try.
By Elena Ciobanu
Frontend Developer, Grundfos
About me
My name is Elena, I’m originally from Moldova, and have been living in Denmark for 5 years. I have a bachelor in Computer Science and a master’s in Media Technologies which led me into the frontend development industry. I’ve been a developer at Grundfos for 3 years and have mainly worked on building the web interface for digital offerings.
References
GraphQL. (n.d.). Retrieved from https://graphql.org/
Reactjs. (n.d.). Retrieved from https://reactjs.org/
TypeScript. (n.d.). Retrieved from https://www.typescriptlang.org/
