Node Yourself Up for Success
On November 18th 2021, Seven Peaks Software held an online meetup, to talk about Node.JS Development. The topic that we chose was NODE Yourself Up for Success. 3 speakers of Node.JS experts giving out their knowledge and expertise to guide you through to be successful with the Node.JS.
NODE.JS MEETUP SUMMARY – Introduction to Node.JS & Frameworks
The meetup opened by Sebastien Dujardin by presenting an introduction about node.js and web frameworks for Node.js. In the introduction about Node.JS, Sebastien talks about some of the fundamental aspects from Node.JS, such as what is node.JS, its history and its main features. On the Web Frameworks for Node.JS part, he went deeper on two main frameworks, KOA and Express. He also compares both frameworks together with its main differences.
Going through Node.JS Main features, there are 3 key distinctive point that can be seen as its features:
- Single threaded
- Asynchronous & non-blocking
- The Event Loop
Moving to the frameworks, There are two popular frameworks that being discussed during the webinar: Express and KOA
So if we re-render from the very top of the react tree it will affect all the components down to the last node and it will bring a big effect on the performance. So you might want to optimize for the re-render at the very top so that it doesn’t need to re-render from the top very often.”
“Express is a fast, opinionated, minimalist web framework for node.js” – https://expressjs.com
Express has so much lower abstraction from node.js that you feel like you’re coding a native node application and that is why many developers that start using express are able to use it very fast as it has little effort to learn. Some fact about Express:
- Downloads per week: 18+ million
- Github Stars: 54k+
- First released version 0.0.1 in January 3, 2010 by TJ Holowaychuk
- Most popular framework and most mature
- Requires Node.js 0.10 or higher
- Latest version: 4.17.1
Going to the next framework, KOA, it actually comes from the same team of express and it comes from version three. The team realized that their design was quite different, actually fundamentally different from express, that instead of releasing a version four they decided to rewrite an entire library. Some fact about Koa:
- Downloads per week: 1+ million
- Github Stars: 31k+
- TJ Holowaychuk made the initial commit on August 17, 2013
- Koa is cooler and hotter in the framework game
- Requires Node.js 7.6.0 or higher for ES2015 and async function support
So what are the main differences between Express and KOA? You can find it below:
- “augment node” (closer to Node.js)
- Built-in routing, templating…
- Middleware chain is callback-based
- Error handling goes at the bottom
- “fix and replace node” (ctx)
- Requires modules: routing, templating
- Middleware chain is Promise-based
- Error handling goes at the top
NODE.JS MEETUP SUMMARY – Structuring Node.JS Projects
The second speaker, Denis Pshenov, dive deep dive deep on Structuring Node.JS Projects by getting into Structuring your Node.JS app, DI Container, Async Local Storage, Request handlers, Services, Unit of Work and Testing.
When you start a project, you will ask yourself how do I handle errors? How do I write middleware? Where do I put services? What is my domain? For a beginner developer this question might be difficult to answer but if you are a mid- level developer or even a senior those questions are pretty easy to handle. To make it easier denis give you some points on to look on on answering those questions, these are:
- Opinionated vs Flexible
- Convention vs Configuration
- Declarative vs Procedural
- Open-Source vs In-House
We could understand frameworks such as Nest.JS and Next. JS Fall into more on the left side where it’s opinionated, Convention, Declarative and Open Source. Meanwhile Express.JS falls into the right side where it’s flexible, Configuration, Procedural and in – house.
So in the end you will have this infrastructure where you have handlers, services and inside of it is the domain and the dependency is always going in as the layers from inside they don’t use the layers from the outside so the drivers are on the outside and they’re in they’re driving the driven part that’s inside.
Lastly, Denis also suggests being very deliberate about your errors, defining your errors, defining classes for your errors, defining error codes for your errors, it should be very clear what errors you have and don’t just assume errors. Be very clear about your status codes and think about ORM. It is highly suggested to take a look at MikroORM.
Lastly, focus on integration tests first if you or your team have a tight budget. Because those will give you the most value and will be the easiest for you to write at least in the very beginning.
NODE.JS MEETUP SUMMARY – GraphQL VS Rest API
The last speaker, Georgii Shestakov, walked you through on GraphQL VS Rest API. There are several ways to create backend APIs. REST is the most common choice but it has some limitations. It’s where GraphQL comes as an alternative to REST.
Rest API is an architecture where api exposes functionality with the resources, with the data, with the object and clients can access it. Every resource basically comes with its own url and client can access to this resource by this url so when client calls rest api they can use normal http methods such GET, POST, PUT, PATCH and DELETE. It Supports a wide range of data formats, such as JSON, XML, or YAML. However, JSON is a primary format now.
There are some limitations with the Rest API:
- Multiple round trips of requests required to fetch all the data needed
- Over Fetching / Under Fetching
- No specific, standardized methodology of structuring REST APIs
Moving to Graph QL, it’s a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.
In GraphQL, a set of information is seen in the context of a graph. Nodes, which are defined using the GraphQL schema system, represent objects. Edges represent the connection between nodes in the graph. You can combine different entities in one query and you are able to specify which attributes should be included in the response on every level.
When a GraphQL server responds to an end user’s request, it begins with the query root, and the resolver executes every field on the requested object.
The limitations with Graph QL are:
- Loss of HTTP level caching
- Performance issues with complex queries;give me the information about the users that booked a table for all the restaurants of this brand
- Difficult to monitor and handle errors as it always returns a HTTP status code of 200 Ok
- A learning curve for the developers
So should we forget about the Rest API? The answer is NO.
Obviously GraphQL is a powerful tool and for some projects there are many options to choose GraphQL. But for most projects still, Rest is the best choice especially when you’re carrying about low performance and need to think about complexity.
GraphQL or rest API is still a good option. Every technology have its use cases and this one obviously very good for Facebook that’s why they created today obviously because they need to separate data and for some, use cases for some application can be really useful and as you see for some developers it’s kind of little bit of learning as you it can be easily applied.
Sign up today & start getting tech news.
Get the latest tech trends directly in your inbox each month. And get invited to exclusive events.