Since its release back in 2012, Firebase has received lots of love from the developer community because it aims to remove the burdens many engineers have to deal with during development, including database, storage, authentication, hosting, and more.
One of its core products, the Firestore database, has been a game-changer in the database world because it allows highly flexible schemaless database access. But sometimes, it can be a bit challenging to work with, especially for new developers trying to build CRUD apps with Firestore.
Firestore and, by extension, Firestore is a great product, but it's only one side of the coin. However, to build production-grade applications, an interface is required for users to interact with and services provided by Firebase. Appsmith is the open-source UI framework that fills this gap if you're making something for your colleagues. Appsmith saves you the time of building UI and routers, focusing on the logic and the architecture of your app.
In this article, I will show you how to build CRUD applications using Firestore with Appsmith. We're going to cover the core concepts of Firestore, such as connecting to the database, reading data, and writing to the database by building a Todo app.
Here's what the finished application will look like:
Awesome! Let’s start hacking away.
Firstly, we need to create an app on Appsmith. Go ahead and sign in to your Appsmith account and click on the + create new app button. You should then be taken to a new app where we can begin building our Todo app. You might also want to rename the app from Untitled Application to something like Todo app.
Now that we have a new app setup, we can go on to connect to Firestore. Click on the + button to the right of the DB Queries section, and then the new data source button. We’ll be connecting to Firestore, so select Firestore from the list of supported databases.
On the opened form, fill in your Firebase connection credentials. Note that your Project Id can be gotten from your project settings in the Firebase console. Also your Database URL is <your_project_id>.firebaseio.com.
Lastly, you’ll need your Service Account Credentials. Go to the Service accounts tab in your project settings on Firebase. Click on the Generate new private key button. It’s going to download a JSON file, so copy its content and paste it in the Service Account Credentials input.
Save your connection and we’re good to go!
Now we have a connection to the database and we can begin to make use of it. Assume that we have a bunch of todos from the database with the following structure:
We can easily fetch todos from the database by writing a query. Click on the New Query button on the Firestore card, and let us write a query to get todos.
Give this query a nice name i.e _gettodos. Its Method will be set to Get Documents in Collection. For the collection path, fill in your collection path. And we can go ahead to set the Order By to ["-created"], doing this will sort the documents by their created date. Here’s my query:
Click on the Run button and you’ll get an array of todos from your Firestore database.
Now we can go back to the canvas and display this data using a List widget. Head to the widgets section and drag in a List widget into the canvas. On its configuration menu (called Property pane), replace the content of the Items field with the bellow binding that pulls in data from the get_todos query into the widget:
You wouldn’t notice any change but rest assured that we’re now feeding data from the query into the widget. Now we can go on to display the todos on the List widget.
You can delete the Image widget in the list as we do not have images in our todos
Drag in a few Text widgets to display the todos text and due dates. For each of the respective Text widgets, use the following bindings in their Text property to display data: For the task field
For the due date field. We’re using the built in moment library to format the due date
Great work! The app is coming to life!
Wouldn’t it be cool if we could create new todos? Yeah, let’s do that.
We’ll need a form for this. So, drag in a Modal widget into the canvas. You can close up the modal because will need a button on the UI to open it up. To do this, drag a Button widget into the canvas. On its property pane, set the onClick Action to showModal and the Modal Name to the modal we just created, that is Modal1.
Now clicking on the button should automatically open the modal. Sweet!
On the modal, we’ll need a few new widgets to capture the todo information. So go ahead and drag in an Input widget to collect the task info, and a Datepicker widget to collect the due date info. A screenshot of mine is shown below:
It is also important to rename the widgets so that we can easily access them later on. Here’s a gif showing how you can do that:
Awesome! Now we can go ahead to write the query to create a todo.
Like we did previously, go ahead and create a new query using the Firestore datasource we earlier configured. You can call your query _createtodo and set’s its Document Path to:
What we have above generates a random string ID for the document. Then set its Body to grab data from the Input widgets we configured on the modal:
The script above will run the _createtodo query, after which it will update the list by running the _gettodos query and the close form modal.
Go ahead and give it a try. Fill in a task and set a due date, click on the button to see the magic happen!
The last feature we’ll like to add to our app is the ability to delete a to-do that has been completed. We’ll need a few new tricks to do this.
Let’s go-ahead to write a delete query. Call this _deletetodo. Set this query’s Method to Delete Document then it’s “Document Path* to the following binding which will read the todo_path from the local store API on appsmith:
Now, let’s go and drag a Button widget into the list. For the button’s onClick Action, we need to store the current todos path in the local store and then run the delete_todo query. We’ll also need to update the list by running the get_todos query. Here’s what you need:
Paste that in and give it a test run. Cool right?
We’ve been able to create a full blow CRUD todo Firebase app using Appsmith. Here a gif of the app in action:
Awesome! Now you can click on the DEPLOY button to deploy it and share the app with friends (be sure to update sharing permissions by clicking on the SHARE button).
If you found this helpful, show some love and leave a star on our GitHub repo https://github.com/appsmithorg/appsmith.
You’ve probably heard the story of the enthusiastic developer who worked night and day for two weeks on a shiny new internal tool, only to find Bob in accounts had built pretty much the same thing in thirty minutes with a no-code app builder or a massive, macro-filled Excel spreadsheet. Bob’s software may not have been as stable, scalable, or pretty, but it was delivered quickly and cheaply.
Situations like these leave developers asking some important questions like, when is the best time to actually build software?
Today you’re going to find out why you should be using low-code apps to build internal tools. By leveraging the speed and cost benefits of the new range of low and no-code tools available, you can use your expertise to deliver applications faster than ever before.
As a developer, low-code apps may seem to take away a lot of the legwork and ownership of your applications. After all, you can’t beat the feeling of building an app from scratch, crafting every feature yourself.
But, the positive side of that is that they can handle the repetitive coding you don’t like, enabling you to focus entirely on refining and delivering your vision as quickly as possible.
Understanding these tools and knowing when to use them will help you to deliver value to your clients and co-workers. It will level up your game.
Today, I’ll tell you what “low-code platforms” are and discuss the pros and cons of using them for internal application development. After reading, I hope you are inspired to try some of them and learn for yourself what they have to offer.
You may have heard the terms low-code and no-code floating around and pictured them as something similar. That’s a mistake. Low-code is not the same as no-code.
No-code apps let you develop applications with no coding whatsoever. That’s great for people with no development skills at all, but it means you’re strictly limited to the features provided for you, usually in the form of a drag and drop interface.
Low-code development still requires code but handles the bulk of the application for you, enabling you to concentrate on implementing the task-specific logic you need. With low-code, you can rely on the platform to deal with common tasks that you don’t need to customize and focus your efforts on the core functionality or differentiated business logic.
Internal applications are the apps you use within your organization for everyday business. There are all kinds of these. You may have apps for planning your office schedule, tallying marketing costs, or tracking leads and sales.
Studies suggest an average of eight apps are used by a typical enterprise employee every day. In larger organizations, there can be hundreds of internal tools used by various departments.
In the US alone, companies spend around $300 billion per year on internal apps. Building and maintaining those is a lot of work, so anything you can do to make it quicker is a plus.
There are many advantages to using low-code apps for your internal tools and applications.
First, it’s typically faster to develop low-code applications than traditional software. With much of the application built quickly using visual tools, and common features added at the touch of a button, it takes much less time to get up and running. Research suggests a 50-90% decrease in development time compared to traditional applications.
Tools like UI Bakery have a whole set of templates you can use to get started, so your app gets some structure from the beginning. You just have to adjust it according to your specific needs.
Since low-code apps are quicker to develop, they are usually cheaper because the biggest cost of a software project is developer time. While you may pay a monthly fee to the toolmaker, it rarely eclipses the thousands of dollars per month that each developer on your team is paid. This cost argument is especially helpful if your management team needs persuading. Show them the figures and see their faces light up.
The built-in features that low-code apps include will be updated along with the platform. That saves you from having to do maintenance. If you need a security fix or need to accommodate an API change, you can just build your app using the latest iteration of the software, and all should be good.
Being able to integrate quickly with other platforms is also a big plus. Many low-code apps let you quickly share data with other software. This could include Zapier, Airtable, Discord, or a whole host of other applications. Integrating with these yourself can take time, so being able to do it with a few clicks can save you a lot of headaches.
Returning to the speed point, if you’re not sure which service to work with, low-code apps can let you make changes so quickly it becomes cost-effective to experiment until you find a service that fits what you are trying to build.
This rapid iteration allows you to take risks and improve your app through trial and error on a scale that would be much more expensive with traditional development.
It also makes low-code solutions ideal for prototyping. You can test out the basic functionality of a new idea, then shift to building a full application if you like it, and want to take full control.
Building things, using them, and improving them is a virtuous circle and participating in it is its own reward. If you like making things, you can do so quicker with low-code applications.
If you do get stuck while building a low-code application, you can take advantage of their support offerings. While these vary depending on which tool you choose, most platforms will at least offer support forums that are more focused and friendlier than Stack Overflow.
The level of guidance can also make low-code perfect for newer developers. If your senior developers are all working on customer-facing products, you might be able to deploy some of your more junior engineers to work on low-code apps meant for internal applications.
Finally, developing low-code apps quickly is a lot of fun. Most developers look forward to building and crafting their ideas and are less keen on the accompanying drudge work involved in many long-term software projects.
"I'm having a lot of fun playing with @roamhacker's smartblocks
A low-code tool in my second brain 🥳
— Samuel Bars 𐃏 (@samuelbars) December 11, 2020
Low-code applications let you focus on the core experience. If you really want to customize the rest, there’s nothing stopping you from using what you’ve built as a starting point for a full project in another language.
Happy developers can realize their ideas quickly and can learn more in the process. The big picture experience that comes through working on multiple projects can also be acquired faster.
So, how about the drawbacks? There are a few, and you need to be aware of them when picking a technology to use.
The key limitation with low-code platforms is that they can’t do everything you can with regular code. Having things done for you is great, but if you want to deviate from what’s offered, you might not always be able to.
You’re effectively working in a box. It may be a nice box, but there’s only so much you can do inside it. As low-code tools improve though, the boxes are getting bigger and better.
Drag and drop components might look great but have a cookie-cutter feel. If you want to make your UI look distinct or offer functionality that is tailored to your needs, not all low-code tools will work.
The same goes for integrations with other tools and platforms. You’ll get a fixed set of available options, which can be added quickly and easily. When you want to move beyond those, you might not have the option, or you might have to build the integration yourself.
The cost was in the positives too, but you also need to check the cost before making a decision. The goal is to save money, after all.
That can add up quickly if you have a large team and could start to outweigh the cost of building a small app yourself.
Just because low-code is potentially cheaper doesn’t mean you can ignore the business side of things altogether, so weigh your options carefully. Don’t assume it’s cheaper in every situation.
The creativity and problem-solving abilities developers possess can be turbocharged by using low-code apps effectively. If you’re new to this booming area, take a look. You might find yourself hooked. You might also find yourself delivering value to your customers at a rate you didn’t previously think possible.
A great option if you want to dip your toe in the water is Appsmith. You can sign up in a few seconds, and the tutorial will show you the ropes in a few minutes. After that, you have a drag and drop interface letting you add UI elements quickly, and, of course, you can alter the core behaviour via its code.
Play around with it and see for yourself what these tools can do. The gap between an idea and its realization is getting smaller every day. Take your first steps on the journey. Who knows where it will take you?
Author Bio: James Konik, Uncertain if he's a coder who writes or a writer who codes, James tries to funnel as much of this existential tension as possible into both of his passions but finds it of more benefit to his writing than his software. When occasionally hopping out from behind his keyboard, he can be found jogging and cycling around suburban Japan.