Meet Your New BFF: Backend to Frontend without the Duct Tape

Rate this content
Bookmark
Slides

Even with all of the incredible frameworks available today vs. a decade ago (or even two––for devs who have been around as long as I have), it still feels like much of our work as fullstack developers is still repetitive, and held together by duct tape code we shouldn’t be writing.  

This is because we write a lot of duplicate and boilerplate code for everyday things such as simple database CRUD, data validation, authorization, and data-type conversions, but the majority of these tasks haven’t advanced at the pace of modern web architecture.  

In this live coding session we'll turn a front-end React app into a fullstack app with code that is easy to write, follow, and, most importantly - maintain with end-to-end typesafety (say no to GraphQL!), consistent and encapsulated validations, live querying, access control, secured APIs, you get the idea. You’ll come away from this session able to build apps for modern web architecture while still maintaining our code DRY and increase productivity while you’re at it through a fully open source and common [React / Vue etc.] stack.

7 min
06 Jun, 2023

Video Summary and Transcription

Noam, the creator of Remalt, explains how this Open Source remote framework can simplify the process of writing a Node.js backend for a React app. He demonstrates using Remalt for full-stack development by adding card capabilities to a front-end to-do app. He shows how Remalt can handle server-side sorting, filtering, and real-time updates. Noam also discusses the importance of data validation and access control, and how Remalt can provide a unified approach to these concerns. He invites viewers to visit the Grimmult website for tutorials and examples.

Available in Español

1. Introduction to Remalt

Short description:

Hi, I'm Noam, a full stack developer and the creator of the Open Source remote framework. Writing a Node.js back end for a crowd-intensive React app is tedious and time-consuming. Let me show you how with Remalt we can fix that.

Hi, I'm Noam. I'm a full stack developer and the creator of the Open Source remote framework. Writing a Node.js back end for a crowd-intensive React app is tedious, repetitive, and time-consuming. Each domain entity requires model types, REST APIs, server-side paging, sorting and filtering, data validation, access control, and eventually an ORM or SQL.

To make things worse, a lot of this code is duplicated on our front-end in the form of front-end validation or front-end access control. Let me show you how with Remalt we can fix that.

2. Using Remalt for Full Stack Development

Short description:

Here we have a front-end To-do app written using React and Next.js. Our application uses the task type to define the task. We've asked Remalt to add full-stack card capabilities based on this task. Let's go ahead and use that in our front-end code. By default, it gets all the tasks for the backend, but we can limit it to get the top two rows and get the second page. And I can say, Order by completed ascending. So I get server-side sorting. And I can filter using completed true or false or undefined to not filter. Now, currently multiple users don't see changes that are done by other users. Let's fix that using Grimal. Another important concern is data validation. Currently the user can add empty tasks and we want to prevent that.

Let me show you how with Remalt we can fix that. Here we have a front-end To-do app written using React and Next.js. In our To-do app, our users can add tasks, complete them, and delete them. In the API side, we've already configured catch-all routes for NextAuth and for Remalt. We've asked Remalt to use Postgres database and to get the user from NextAuth.

Our application uses the task type to define the task. Let's ask Remalt to add full-stack card capabilities based on this task. We'll add an entity decorator, we'll support all card capabilities, and we'll add field decorators. And we'll head over to the entities array and register the task type. As soon as we do that, we get a REST API that returns the tasks that are in the database. Let's go ahead and use that in our front-end code. We'll head over to our todo component and the first thing we'll do is define that task repository. And then we'll use that repository to load the tasks, to insert new tasks, to save changes to existing tasks, and to delete tasks. And that's it. That's all we needed to do to create a full stack app. I can add tasks, I can check tasks, I can delete tasks, and all our standard REST API operations, Get, Post, Put, and Delete, all using standard REST API.

Let's zoom in on define method. By default, it gets all the tasks for the backend, but we can limit it to get the top two rows and get the second page. And we get server-side paging. And I can say, Order by completed ascending. So I get server-side sorting. And I can filter using completed true or false or undefined to not filter. And all of that uses standard REST API So just by defining these four decorators before, we were able to get full stack a query language that is fully typed end-to-end from the frontend to the backend.

Now, currently multiple users don't see changes that are done by other users. Let's fix that using Grimal. To do that we'll replace find with live query, then we subscribe, and subscribe gets an info object that we can use to apply changes to our task. We'll also return the result so it will unsubscribe when the component unmounts. Now, as soon as we do that and refresh both our browsers, any changes that are done by one user automatically reflect to all the other users. Another important concern is data validation. Currently the user can add empty tasks and we want to prevent that.

3. Validating Tasks and Access Control

Short description:

Let's set up validation for our tasks to ensure a single source of truth. By implementing validation logic on the task title length, we can provide front-end validation without making any network calls. This validation code is also used to validate API requests, ensuring consistent validation between the front-end and back-end. Additionally, access control allows only authenticated users and admins to access and insert tasks. Grimmult enables a unified approach to end-to-end typing, validation, and access controls, compatible with popular stacks and databases. Visit Grimmult.dev for tutorials, guides, example projects on GitHub, or join the Grimmult Discord channel.

Let's set this validation on our task of a single source of truth. I'm going to say over here task validate and I'll write my validation logic if task title length is less than 2, throwError to short. As soon as I do that and refresh the browser if I try to add an empty task I will get a validation error but note the network tab. There are no network calls being made so this validation code then in the front end provides us with front end validation.

Let's try to bypass that and send a post call to the backend with an empty title. As soon as we do that we get the same validation the same code that we've written also to validate API so we get consistent validation between the API and the front end using the same code.

Another important aspect is access control. I only want authenticated users to be able to access the data and I only want admins to be able to insert new tasks. As soon as I save that and refresh the browser we can see that I killed the tasks because I'm not authenticated. Now when we've set up NextOS we've configured two users, Jane who's an admin and Steve who is not an admin. Let's try those and see what happens. I'm going to sign in as Jane and here I can see the tasks and I can add another task. Let's sign out and sign in as Steve and we can see that Steve cannot add a new task because Steve is not an admin.

Now let's improve the user experience to also not allow users who are not allowed to add, they shouldn't really see the phone. So let's go to our task component or to-do component, highlight the form and he will say from our repository, if the metadata says that API insert is allowed, only then show the form. So now Steve doesn't see the form anymore but if I sign out and sign in as Jane, Jane does see the form and is able to add. So this is how using Grimmult, we can maintain a single source of truth for end-to-end typing, validation, and access controls that is shared between the front-end and the back-end in a consistent manner. Grimmult already works with most popular stacks, most databases and can be deployed to any Node.js server or serverless cloud. Ready to check out Grimmult? Head over to Grimmult.dev and see our tutorials and guides. Check out our example projects on GitHub, or say hi on the Grimmult Discord channel.