Building a news app with low code platform Flutterflow: Lessons & Insights

Low code platforms have come a long way since their beginning, and with the coming of AI, the possibilities of these platforms is growing exponentially. To better understand these tools we've built a Proof-of-Concept news app, the challenge: Reduce the amount of code written to a minimum, and see if we can build it faster than using traditional coding methods. Interested in the outcome? Read our experiences below!

The content source

The first thing we needed was a contentsource to populate our app. We could've used open API's like the Star wars API, however we felt that this API was "too clean". Like any developer will testify, real world production API's are most of the time poorly documented, bloated, and filled with legacy items. Unless it's an API we've written ourselves. In that case, it's written perfectly.

So in search of our content source, we've chosen to set up a Contentful CMS. It's a headless CMS that's plug and play, and provides an easy to use API. Because we only needed a demo blog; the entire set-up and deploy was done in under 30 minutes. Thank you Contentful CMS, you are lovely. We'll get back to swearing at you when we actually start using your API.

The mobile app platform: Flutterflow

When researching a variety of low code platforms, Flutterflow was the one we noticed as the most mature platform out there for mobile development, so we chose to go forward with this tool. Traditionally we've been on "Team React Native", but we did not find a suitable platform that had feature parity with Flutterflow and the underlying new dart programming language. 

The UI

Building the UI was actually a very nice experience. If you are familiar with design tools like Figma or webbuilders like webflow or framer, you will feel right at home in Flutterflow.  The pages and components are on the left, on the right you can find details of the selected page or component, and you have all the styling features one can expect from a visual builder.

The flutterflow application provides you with all the necessary components to build and style a page like texts, video's, lists, grids, media,...  and with a variety of predefined templates, you can easily adapt one to fit your needs.  

Configuring the API and binding the datafields

After building the UI, we started thinking our coding days were over, and all developers could be sipping margarita's while designers did everything, but alas, we're not fully deprecated yet. 

Allthough Flutterflow provides you with a very intuitive interface for setting up the API, you still need some technical knowledge, for example: setting up the HTTP request headers for authentication etc.

After setting up the base API, you can set up the different endpoints for collecting the data you need. In this instance, we needed to get all blogposts. After looking through the documentation, we found that this was easily done with the Contentful entries endpoint, with the query parameter content_type set to the right variable.  You can test this endpoint in flutterflow and immediately know if your endpoint is retrieving the right data. 

However, this results in a JSON response that contains a lot of information, most of which we didn't need for this simple example. With JSON path you can pre-define variables to be used in Flutterflow, based on the response of your API request. We'll be honest, it took some time configuring this our first time, as flutterflow didn't provide the best error logging. The interface does provide you with ample help to retrieve all parameters, but saying the contentful API provides a lot of data, would be an understatement.

After we've set up our base API, our endpoint, and defined our variables, we can go back to our screens and feed them with the right data. Flutterflow has different types of view that can contain iterative data (Lists, grids)... When you bind it to a datasource, it immediately creates child entries for every received entity.

Binding the content to the list, and binding the invididual datafields to the right textfields is done yet again with JSON path. Without proper debugging tools it can be quite tricky to find the right selector for the exact items you need. This is where a background in development can come in handy, and where UI designers might run into obstacles.

However once this is done, you have a working blog post overview!

Setting up the notifications: Firebase and Google Cloud

The second aspect of our news app consists out of sending a notification when a new blogpost is published. So how do we start? We need a way for Contentful to let our app know there is new content available. Luckily for us, Contentful has a native webhook functionality. (This should be available in every modern headless CMS)

Now we know Contentful can come knocking when a new blogpost is published. The question now is, where does it need to knock? As we're trying to build this without custom code, and without our own servers, we look towards Firebase. Firebase is a set of back-end features provided by Google, that fits our need entirely. Firebase can provide us with the following:

• An authentication system for our users (You need to consent for notifications)
• A database to store our users and notification data. Firebase uses the Firestore NoSQL database.
• Cloud functions to receive the webhook data and send the notifications

Flutterflow has native support for firebase, and provides easy tutorials to follow. Without going into too much detail: You set up a project in Firebase, you give access to Flutterflow to read and write to firebase, and from there you can do any further configuration from inside flutterflow.

With a few clicks you can set up authentication and notifications in flutterflow and firebase. This sets up the necessary collections in firestore and the cloud functions to enable these features.

Enabling notifications in Flutterflow triggers the creation of the sendPushNotificationsTrigger. This Cloud function tracks any change that is made to a firestore collection called ff_push_notifications, and sends the content of newly added documents as a notification to all consented users.

Knowing this, we can leverage a custom made cloud function to send our contentful webhook data as a notification to our mobile app users.
However, as we were in our "low code" challenge. We obviously couldn't code this cloud function ourselves.

Thanks bro.

We needed to edit the code a bit, but 90% of the setup was done thanks to ChatGPT, when we gave it a sample of the body of the request that is sent in the webhook. After that we saved the cloud function in flutterflow, and we went to the Google cloud console to get the URL where our cloud function could be triggered.

This is the URL that we then pasted in as the target URL of the webhook in the contentful platform.

With this configured, we now have a fully operational notification system, built with serverless google cloud functions. This approach allowed us to build a low effort, but very scalable solution, as the google cloud platform can be configured to send notifications to millions of devices.  The final setup of the notification flow looks like this:

Conclusion

In our experience, lowcode tools like Flutterflow are a welcome evolution in the development scene. It expedites mundane tasks like building the UI of basic login and overview pages, and allows development to focus on more critical technical parts of the application, while the designers can take more responsibility in building the front-end. We definitely see a bright future in Figma - Flutterflow connections.

This approach to building apps also frees up time to strategize about the so-called "non-functions" like scalability, security, maintainability, privacy etc...
While the lowcode platform can take you quite far in the simple building of stand-alone mobile applications, in most real world situations, you will always need to think about connectivity to other systems. In a way, the limits of low code, force you to think of the best scalable solutions for back-end services, and cloud development, like Google Cloud, AWS or Microsoft Azure are presenting themselves as natural and powerful back-end partners for lowcode solutions.

So, are we developers out of a job? We don't think so, but we're definitely evolving from builders to architects that engineer solutions, leveraging a toolset that is continuously getting more powerful.