DEV Community: Lennox Charles

5 Full-Stack JavaScript Frameworks 2024

Lennox Charles — Tue, 05 Mar 2024 15:36:12 +0000

The web has never been more amazing and robust than now. I am a big fan of the web, and I like to share whatever knowledge I gather about it. In this article, I will introduce you to a few full-stack JavaScript frameworks that you can start learning about from the many available ones, in no particular sequence.

Let's begin!

Next.js

Next.js is a React framework for building full-stack web applications. You use React Components to build user interfaces, and Next.js for additional features and optimizations.

Under the hood, Next.js also abstracts and automatically configures tooling needed for React, like bundling, compiling, and more. This allows you to focus on building your application instead of spending time with configuration.

Whether you're an individual developer or part of a larger team, Next.js can help you build interactive, dynamic, and fast React applications.

Get started.

The Boring JavaScript Stack

Whether you prefer the simplicity of Vue, the flexibility of React, or the efficiency of Svelte, The Boring JavaScript Stack accommodates your choice. With The Boring JavaScript Stack, the UI of your app is simply the components of your chosen UI framework.

So if you enjoy writing React's JSX, you'd love The Boring JavaScript Stack, as that's the only thing you have to know about React - writing components. Same thing with Vue and Svelte.

Get started.

Nuxt.js

Nuxt is a framework designed to give you a strong architecture following official Vue guidelines. Incrementally adoptable, it can be used to create everything from static landing pages to complex enterprise ready web applications.

Versatile by nature, it supports different targets (server, serverless or static) and server side rendering is switchable.

Extendable with a strong module ecosystem, it makes it easy to connect your REST or GraphQL endpoints, favorite CMS, CSS frameworks and more. PWA and AMP support is only a module away from your Nuxt project.

NuxtJS is the backbone of your Vue.js project, giving structure to build your project with confidence while being flexible.

Get started.

Sails.js

Sails is, of course, a web framework. But take a step back. What does that mean? Sometimes, when we refer to the "web", we mean the "front-end web." We think of concepts like web standards, or HTML 5, or CSS 3; and frameworks like React, or Vue.js, or jQuery. Sails is not "that kind" of a web framework. Sails works great with React and Vue, but you would never use Sails instead of those libraries.

On the other hand, sometimes when we talk about "web frameworks", we mean the "back-end web." This evokes concepts like REST, or HTTP, or WebSockets; and technologies like Java, or Ruby, or Node.js. A "back-end web" framework helps you do things like build APIs, serve HTML files, and handle hundreds of thousands of simultaneous users. Sails is "that kind" of web framework.

Get started.

Nest.js

Nest (NestJS) is a framework for building efficient, scalable Node.js server-side applications. It uses progressive JavaScript, is built with and fully supports TypeScript (yet still enables developers to code in pure JavaScript), and combines elements of OOP (Object-Oriented Programming), FP (Functional Programming), and FRP (Functional Reactive Programming).

Under the hood, Nest makes use of robust HTTP server frameworks like Express (the default) and can optionally be configured to use Fastify as well!

Nest provides a level of abstraction above these common Node.js frameworks (Express and Fastify), but also exposes their APIs directly to the developer. This gives developers the freedom to use the myriad of third-party modules that are available for the underlying platform.

Get started.

Conclusion

As mentioned, these frameworks were listed in no particular order. Personally, I have 3 out of the 5 mentioned in this article, and they are commendable with their pros and cons.

Do have fun with them, and feel free to connect with me about your learning progress.

Quick and easy loading spinner without JavaScript!

Lennox Charles — Mon, 04 Mar 2024 19:47:32 +0000

In this article, you will learn how to set up a quick and easy loading spinner using just Tailwind CSS. Stick around till the end to get the extra feature.

Why use Tailwind CSS, not JavaScript?

The reason for using Tailwind CSS is to reduce the amount of JavaScript being shipped with the framework you are making use of. The less JavaScript you have, the more lightweight your web application becomes.

The Spinner

Working with Tailwind CSS helps you ship faster, and you don't need to spend so much time styling or organising your CSS files.

Let's get started.

<div class="flex items-center justify-center h-[50vh]">
  <div class="animate-spin rounded-full h-16 w-16 border-t-2 border-blue-500"></div>
</div>

That's all you need to get a simple loading spinner in your web application.

animate-spin: This class adds a rotating animation to the element.
rounded-full: This class makes the element a perfect circle by rounding its corners.
h-16 w-16: These classes set the height and width of the spinner. You can adjust the values based on your design.
h-[50vh]: This class sets a responsive height for all screens.
border-t-2 border-blue-500: These classes add a border to the top of the spinner, creating the appearance of a spinner with a specific color (blue-500). You can customize the color by choosing a different Tailwind CSS color class.

Make it Reusable

An extra is to show you how to make it reusable in Vue and React.

Vue

<template>
  <div class="flex items-center justify-center">
    <div class="animate-spin rounded-full h-16 w-16 border-t-2 border-blue-500"></div>
  </div>
</template>

<script>
export default {
  name: 'Spinner'
};
</script>

<style scoped>
/* Add any scoped styles if needed */
</style>

React

import React from 'react';

const Spinner = () => {
  return (
    <div className="flex items-center justify-center">
      <div className="animate-spin rounded-full h-16 w-16 border-t-2 border-blue-500"></div>
    </div>
  );
};

export default Spinner;

You can conditionally render the loading spinners when updating a state or fetching data from an API.

Resources

Estimate the read time of an article without any library in JavaScript.

Lennox Charles — Fri, 01 Mar 2024 20:56:19 +0000

In this article, we'll embark on a journey to craft a JavaScript function to help us estimate the read time of an article. You will dabble with a little bit of regex to help you strip your content clean for proper estimation. Keep in mind that since this is pure JavaScript, it works across the stack (front-end and back-end).

Let's get started.

Strip HTML Tags

If there are HTML tags present in your content, you will need to strip the content to make the estimation more accurate.

To do that, we have to do some regex:

const htmlTagRegExp = /<\/?[^>]+(>|$)/g
const textWithoutHtml = text.replace(htmlTagRegExp, '')

htmlTagRegExp: The regex function catches any HTML tag syntax.
textWithoutHtml: The .replace property replaces the HTML tag syntax caught by the regex with a blank space.

With that, we achieved the first phase of the estimation.

Match all words

const wordMatchRegExp = /[^\s]+/g
const words = textWithoutHtml.matchAll(wordMatchRegExp)

wordMatchRegExp: This regex function is used to match all non-whitespace characters. It's designed to match individual words in a text.
words: The matchAll method is used to find all matches of the regular expression in the given textWithoutHtml. It returns an iterator containing all the matches.

Let's Estimate!

To estimate the read time of the content, you will unpack words and get the length as the word count. Then you divide it by 200. Why? because 200 words per minute is the assumed average reading speed.

const wordCount = [...words].length
const readTime = Math.round(wordCount / 200)

With that, you have gotten the estimated read time of your content.

Conclusion

You can always set this up as a reusable function in your project and make use of it without installing any additional packages.

See you on the next one.

"API Thinking" - Know your audience category

Lennox Charles — Sat, 25 Mar 2023 17:47:27 +0000

When building an API (Application Programmable Interface), no matter what stage you are in the process, it is always important to correctly identify your target audience. This step is essential when developing an API, why?, it will enable you to know how to market your API correctly and to the right people.

However, there are lots of benefits when you find the right audience for your API. I'll be concentrating on the three main categories into which your audience might be segmented in this article.

PS: In subsequent posts, I will talk about knowing your target audience, I would recommend you stick around, just a piece of friendly advice ;-)

Now let the fun begin!

3 Categories of audiences

Private APIs

You might have heard of this before-but if not-No, this is not an API running on your local desktop. This is an API that exposes part of an organization's backend data for developers working in the same organization. Gotten an idea?

Private APIs can have usage limits and can only be accessed by authorized users. A simple scenario where private APIs are frequently used is for businesses to grant authorized employees and partners access to their internal data and systems.

One key benefit of private APIs is they can significantly reduce development time and resources.

FOOD FOR THOUGHT

The purpose of a private API is to make it possible for internal developers who are creating new apps to utilize existing systems like the backend already being used by the organization. You need to ensure that the program satisfies both the organization's short-term project objectives.

Public APIs

Now, this is the famous one, public APIs are designed to be easily accessible by a wider population of web and mobile developers. It can literally be used both by developers inside and outside the organization.

This category of APIs helps smaller organizations create organic interests in their core business values. Although it can generate revenue if usage is substantial, it can also be used as a marketing channel for smaller businesses.

FOOD FOR THOUGHT

A public API's success will depend on its capacity to draw outside developers and assist them in building genuinely useful new applications that users actually desire to use. The primary objective should be to promote API usage, both in terms of quantity and quality.

Lastly,

Partner APIs

These APIs are typically used to support apps created by programmers working for a company that already has a working relationship with the API developer.

Sounds similar to private APIs right? Let me clarify that for you:

Partner APIs are private APIs that have been made available for authorized partners only. It may have special terms and conditions concerning its usage.

Now you see the difference? of course, you do.

To implement a partnership API, the API developer will need to have knowledge and direct access to the client developer application.

FOOD FOR THOUGHT

Be as it may, the API developer or designer will need to have access to the developer application, but they lack direct influence or authority over the developer.

Regardless, it will be good to know how the API will be used and by whom.

BONUS: Where to find APIs you can use

As an added bonus to this essay, I'll show you some places where you can find APIs to use or recommend.

DISCLAIMER: I have no affiliation whatsoever to these sites, just sharing a resource.

RapidAPI.com: The largest API marketplace in the world, RapidAPI, with more than 10,000 APIs and one million active developers. On this website, cutting-edge APIs are categorized according to the industries in which they are used.
ProgrammableWeb: ProgrammableWeb is a strong API repository with the largest, hand-curated API directory in the world, with an estimated 17,000 APIs. This website, which was created by Mulesoft, also offers a ton of news, press releases, tutorials, reviews, and articles about APIs.
API List: Since its 2017 launch, API List has become one of the web's most trustworthy sites for API information. There are several APIs available on this site, including more than 800 free APIs.
API For That: API For That is another top-notch website where you can get a hand-curated directory. The portal features over 400 API profiles in over 20 industrial areas. Additionally, each API in this repository comes with a description, some basic documentation, and a link to the webpage of the provider.

I could give a long list but you could easily find these resources on google, or whatever search engine you use.

Cessation

Knowing the category your API falls in will determine how you search for your target audience. These categories only help to streamline your audience research.

That's a wrap! Thanks for taking out time to read this post. See you in more subsequent posts. Feel free to use the comment session if you have any thoughts or corrections.

Getting started as an API developer

Lennox Charles — Wed, 22 Mar 2023 09:57:57 +0000

As we delve deeper into the technological era, we discover more possibilities. This explains the rise of AI and so many other trending technologies and frameworks.

Companies are now looking for technologies to increase their productivity and profit margins. Most of that challenge is solved with APIs (Application Programmable Interfaces). Having API skills allows you to facilitate interaction between various servers and applications.

For that to be possible, you need to embark on the journey of acquiring API-related skills and launch a career in API development. In this article, you will see what skills you need to get started. Drumrolls!

API development skills?

Before getting to the nitty gritty, let's clarify some basic knowledge. An API serves as a messenger between two communicating servers or applications. It takes a request from the sender and sends it to the receiver; after processing the request, the receiver sends a response back to the server.

Having API development skills will enable you to develop these "messengers"—an application or piece of software—that can perform that task.

Slightly confused? Here's a basic example: You can connect your phone to a smartwatch to receive calls and read messages. An API is what makes that possible. It helps connect applications together to exchange information and perform any pre-defined task.

Now that's out of the way, let's get to see some skills.

5 API development skills

Keep in mind that these are not all the skills required, this is just enough to get started. These skillsets are:

Language proficiency in coding
It is advisable for an API developer to have coding skills in a variety of languages. This makes sure you are using the appropriate language for the project you are working on. By all means, feel no pressure; it takes a lot of time to get a proper grasp of one language.
Protip: Learning the foundations of one language will make it easier to learn others.
Designing an API
Knowing how to design an API is important because the better the design, the more enjoyable the experience of making use of it will be.
Protip: The better your API design, the more features are possible.
Platform Independence
This skill allows you to build an application that works on diverse platforms with little or no maintenance.
Protip: Building platform-independent applications helps you narrow your focus, thereby improving productivity.
Knowledge of service-oriented architecture (SOA)
It is all about being able to reuse your components when developing an API and being able to identify when an existing API has the functionality they need in their new API.
Protip: Reusing components speeds up the development time of new features or versions.
Fluency in communication
Being able to document how your API works is important to ensure understanding for the users. Of course, to avoid answering a bunch of questions you might probably lose track of the answers.
Protip: Documentation helps present a clear and concise understanding of the API operations to the users.

Bonus: Simple tools you need to know

Swagger: an easy-to-use tool that helps you auto-document your API and provide a live interaction.
Redoc: similar to swagger, but no live interaction.
Databases: helps you store the data sent to your API. There are different types you can make use of, e.g MySQL, Postgres, MongoDB, etc.
Postman: makes it easy to test your API.

Cessation

The journey is continuous; do not be afraid to try new things. Continuous improvement is always better than delayed perfection. However, having a good source of information or knowledge will certainly boost your progress.

Know Your HTTP Verbs - HTTP verbs for beginners

Lennox Charles — Thu, 16 Mar 2023 19:48:08 +0000

It is quite inevitable to use the wrong HTTP verb when developing your API, especially as a beginner. I once faced the same contingency when I was at the beginning phase of developing APIs. I knew what each verb meant, but I ignorantly misused them.

After several projects and tutorials, I realized that I was following the wrong approach. With more understanding, I was able to practice using the right HTTP verb for the right purpose. That is what I will be showing you in this post.

Before we get started, I believe we should cover as much as possible. Let's get to know what HTTP verbs are and why you should use them correctly.

What are HTTP verbs?

HTTP stands for "Hypertext Transfer Protocol," and it is considered by many—myself included—to be the life of the web. When it comes to transferring documents or making a request, HTTP is the backbone. In simple terms, it is a protocol responsible for transferring documents over the web.

Easy right? Let me guess: you have probably never heard of protocols. If you have, I think you should go to the next heading, but if you haven't, "protocols" are a determined set of rules that govern the exchange of information across the web.

Why should I use the right HTTP verb?

As a developer of any stack, it is important to get a hang of the tools you use and be effective with them. Therefore, if you are developing APIs, you need to know how HTTP works. It gives your API an edge and ensures proper usage of third-party developers.

A little need to know

It is important to understand two keywords when it comes to using HTTP verbs efficiently, and those are "safe" and "idempotent."

Safe deals with read-only, which means you can make requests to an endpoint and not worry about any data being updated or destroyed.

Idempotent, on the other hand, means you can make multiple requests to an endpoint without changing anything or getting a different result.

Generally speaking, all safe methods are idempotent, but not all idempotent methods are safe. It's a bit of a conundrum if I must say so, but you are in the right place. You will get the idea as you read more.

Let's get right to it: HTTP Verbs

Additional knowledge is that—after all, you are reading this to learn—HTTP verbs give the server instructions on what to do with the data sent through the URL. Now, let's talk about a few briefly.

GET

You should use get only when you wish to read data, not store or update. Among others, the GET is the simplest verb. Conclusively, now that we know GET is only used for reading and the same data is always returned, we can say that they are safe and idempotent.

POST

Whenever you try to make a POST request, everyone is expecting that you are trying to store something. That is trying to add a new resource to the database. The POST method is said to be neither safe nor idempotent because a new resource is being created, and making two requests to the same endpoint will yield different results.

PUT

You may have come to the thought, "How then do I update?" This is where the PUT request comes in. It is often used in the context of updating resources. PUT can also be used to create new resources, but the client will have to define the ID. Trust me, it gets more complicated, so I won't advise that. What I recommend is to only use this verb when you want to update. It is not a safe operation because it makes changes on the server side, but guess what? It is an idempotent operation.

PATCH

Here is where it gets interesting, PATCH is also used to update resources, but unlike PUT, it updates just the changed data and not the entire resource. It is neither safe nor idempotent. In the real world, PATCH is rarely used.

DELETE

The way it sounds is how it operates. You can simply use DELETE to destroy redundant resources from the database. It is certainly not a safe operation, but some say it is idempotent and some say it is not.

Cessation

Well, if you got to this extent, you have certainly gained one or two points. Another piece of advice I would like to give is that using the right HTTP verbs will make your API more fault-tolerant. Your API will also be more methodical in its operations.

Here's a pro tip: the GET operation should never be used for creating or updating.

That's a wrap! I'll see you again in subsequent posts.

KNOW THE MATURITY OF YOUR RESTAPI

Lennox Charles — Mon, 13 Mar 2023 17:46:11 +0000

Recently, I was working on a FastAPI project; I got the idea from the "Real Python" website. While doing my studies on the project, I came across this model. So I thought I’d take a stab at my brainchild and talk about this.

Leonardo Richardson proposed this model. It is used to grade or measure an API by its RESTful maturity.

Leonardo analyzed hundreds of different web services and considered three factors before coming up with this new idea.

Factors

URI: Uniform Resource Identifier
HTTP methods
HATEOAS (Hypermedia)

Maturity Levels

Level 0: The Swamp of POX

This level is also known as POX (Plain Old XML). HTTP is only used as a transport protocol for interaction between two systems. It does make use of the full HTTP features like HTTP methods and HTTP cache. To perform operations like get and post, it makes use of a single URI. Most of the time, the only HTTP method used is POST. In essence, this level makes use of SOAP web services in a REST style.

For example, most SOAP Web Services use a single URI to identify an endpoint, and HTTP POST to transfer SOAP-based payloads, effectively ignoring the rest of the HTTP verbs.

To get the data: http://localhost:8080/posts

To post the data: http://localhost:8080/posts

Similarly, XML-RPC-based services send data as Plain Old XML (POX).

Level 1: Resources

Level 1 employs many URIs but makes use of a single verb, generally HTTP POST. It tackles difficulty by disintegrating a single service endpoint into multiple endpoints.

For example:

To get the list of posts: http://localhost:8080/posts

To get a specific post: http://localhost:8080/posts/1

Based on the multiple URIs available, makes this level better than the previous.

Pro tip: There will be no required field in the DB, an empty body is to be sent to the API

Level 2: HTTP Verbs

Level 2 generally hosts numerous URIs and supports several HTTP verbs. At this level, the state of resources can be easily manipulated over the network. i.e., it is now able to perform CRUD operations. For each request, the correct HTTP response code is provided.

To get the list of posts: http://localhost:8080/posts

Response code: 200 OK

This is the most popular use case of REST principles. It is mostly done automatically by different frameworks.

Level 3: Hypermedia Controls

This is the peak level, it is quite the combination of level 2 and HATEOAS (Hypertext As The Engine Of Application State). It helps to describe possible interactions and how to carry them out. The links give client developers a hint as to what may be possible next.

For example, when a request is sent, you get a response, a link and a URI.

CONCLUSION

Be aware that any level you get to still makes your API a RESTful one, this is just to grade maturity.

This is a good way to think about the elements of REST but it’s not a definition of levels of REST. Roy fielding made it clear that this is just a pre-condition of REST.

What I find useful about this RMM is that it helps to understand the basic ideas of RESTful thinking. I see it as a tool to help learn about concepts, not something that should be used as an assessment mechanism.

SUMMARY

Level 1 tackles the question of handling complexity by using divide and conquer, breaking a large service endpoint down into multiple resources.
Level 2 introduces a standard set of verbs so that we handle similar situations in the same way, removing unnecessary variation.
Level 3 introduces discoverability, providing a way of making a protocol more self-documenting.

BONUS

Practical implementation: https://github.com/lennyAiko/RMM-model-API.git
This project was coded using flask, swagger and OpenAPI Specification for REST APIs.