DEV Community: Mufassir Kazi

The Best Backend For FlutterFlow 2024

Mufassir Kazi — Tue, 06 Feb 2024 10:31:46 +0000

In the dynamic world of mobile app development, finding the right backend solution can be a pivotal decision, especially when working with platforms like FlutterFlow. The backend serves as the backbone of any application, handling data, user authentication, and overall functionality. As FlutterFlow empowers developers to create stunning apps with minimal code, the quest for the best backend becomes even more critical.

In this article, we embark on a journey to explore and evaluate BuildShip - a lowcode visual backend builder, aiming to guide FlutterFlow enthusiasts towards selecting the optimal backend solution that easily complements their development endeavors. Whether you're a seasoned developer or a newcomer to the FlutterFlow ecosystem, understanding BuildShip can significantly enhance the efficiency and success of your app-building journey.

Introduction to Flutterflow

Before diving in, let's quickly recap FlutterFlow. It's a tool that empowers you to construct user interfaces, establish logical flows, integrate data into your app, and deploy to app stores—all without the need for coding. It aims to simplify the app development process and make it accessible to a broader audience, including those without extensive programming experience.

Understanding BuildShip

Enter BuildShip, an AI powered low-code backend builder that empowers you to create complex workflows, without writing into a single line of code.

Gone are the days of hand-coding with NodeJS, setting up a REST API server, and navigating through manual integrations. With BuildShip, you can now seamlessly integrate in a zapier-style nocode format while retaining the freedom to code your REST APIs in Javascript low-code style. This means you no longer compromise on the limitations often associated with no-code tools; instead, you have the code accessibility to modify as needed, ensuring unparalleled flexibility.

Coding Language: English + Javascript

Imagine hundreds of pre-built nodes at your fingertips, ready to send emails, generate reports, or connect to databases. Just drag, drop, and watch the magic happen.

And if you can't find the node you're looking for, BuildShip's incredible in-built AI can build a custom node just for you. You can even tweak it in low-code, so you're always in control.

In this article, we’ll explore how BuildShip can help empower no-code developers to do full stack development using Flutterflow and BuildShip.

Integrating BuildShip with FlutterFlow

First, let's tackle a key question: Where to begin—front end or back end? It all depends on what your app needs. If you're already using FlutterFlow or need features like authentication from Firebase, start with the front end. But if you're dealing with big data, complex calculations, or non-Firebase databases, kick off your app development journey with BuildShip's backend playground. It's designed to handle heavy-duty data tasks and make backend operations smoother.

Why BuildShip for Flutterflow?

Let’s look at a number of possible reason for why BuildShip is the perfect backend choice for your Flutterflow app

Visual Logic Building: Drag, Drop, and Reorder - Create Logic the way you want: While it might seem simple, a significant aspect of automating or constructing workflows lies in the complexity that can arise as you continue to build your app. With BuildShip, you have these building blocks called as nodes, that you can remove, reorder or customise any way you want.
Time Efficiency: For those familiar with setting up Cloud Functions in the past, the waiting time after hitting deploy was a familiar frustration. Thanks to BuildShip, that's a thing of the past. Now, you deploy once, and subsequent redeployments take mere seconds to reflect changes. This saved time can be put to more productive use—how about enhancing your FlutterFlow UI itself?
Ready to use Database: Versatility in Database Options: Each BuildShip project is equipped with a Google Cloud project that includes Firestore by default, eliminating the need for manual database setup. Alternatively, you can easily connect with a database of your choosing, utilizing either AI or opting from our array of supported database choices, including Supabase, Firebase, Pinecone, and MySQL.
Unlimited Storage for your assets: Not every application needs a constant connection to an online database for data storage and retrieval. Many applications benefit from simply storing data on a user's device. Occasionally, you may need to transfer this data to an online database for safekeeping. BuildShip enables you to store and retrieve data locally, offering the flexibility to build genuinely intricate FlutterFlow apps without being binded to a constant online connection. Better yet, your data is stored in the region of your choice during project creation - making them GDPR compliant for EU regions.
Easy Import, Easy Export: BuildShip provides an incredible export tool, that lets you export your API in the YAML format and have it directly imported into Flutterflow as a brand new API call.
Integrating Payment Apps: Integrating with payments apps like Stripe solely through FlutterFlow can be challenging, particularly when retrieving the payment ID from Stripe. BuildShip, on the contrary, simplifies this process, making it easier to integrate with your Stripe account and showcase all the necessary information on the frontend by passing the data. Below is a template to guide you through it.
Logic Flows and Security: When it comes to making logical decisions on your data and ensuring secure access, what options do you have for presenting it back to FlutterFlow? BuildShip offers utility nodes that empower you to construct logical workflows and easily integrate with any tool for automating various tasks. In terms of security, every time you generate a secret key, BuildShip uses the user's Google Cloud Secret Manager, avoiding the storage of keys in a vulnerable random database. Everything within BuildShip operates on Google's infrastructure, designed for scalability and robust security. No need to navigate the complexities of API calls – BuildShip has you covered.

Flutterflow Community Wishlist

Many FlutterFlow users seek a no-code backend solution catering to complex business logic, organized data structures, secure API requests, and simplified frontend modifications or upgrades.

Queries for a no-code backend is rising, underscoring the demand for BuildShip within the vibrant FlutterFlow community forums:

BuildShip x FlutterFlow: The Full Stack Power Couple 🔥

To integrate with any frontend app, creating an API is essential. This begins by adding a Trigger, and BuildShip provides various triggers tailored to your use case, illustrated below.

For instance, utilize the REST API node to trigger a call from the frontend to a custom REST API you can create yourself. Plus, the compatibility of Flutterflow with REST APIs adds an extra layer of convenience.

In this tutorial, discover the ins and outs of full stack development using Flutterflow and BuildShip. To do this, we’ll build a barcode scanning app that instantly reveals nutritional info, reviews, and even suggested recipes for the scanned product.

Further, scroll down to explore more apps created with Flutterflow and BuildShip, offering insights into the harmonious fusion of workflows and beautifully designed UIs. 🚀

Conclusion

In the realm of FlutterFlow backend solutions, BuildShip emerges as a transformative force, offering a low-code, high-flexibility approach to full-stack development. With features like pre-built nodes, drag-and-drop simplicity, and an AI that tailors custom nodes, BuildShip provides unparalleled control. As you embark on your app-building journey, the choice is clear: BuildShip is the engine that propels your FlutterFlow experience to new heights.

RudderStack - The Open Source Alternative to Segment

Mufassir Kazi — Tue, 25 Apr 2023 16:39:15 +0000

With over 114+ team size and 3.5k+ GitHub stars, RudderStack is the most popular open-source alternative to Segment.

To put it briefly, RudderStack assists you in gathering all your customer event data. Once you have collected it, you can easily send it to various teams within your organisation or third-party tools that require the collected data for further processing.

This blog post covers the fundamentals, core features, integrations, pricing model, growth and the team behind Rudderstack. Let's get started! 🛠️

Where does it all start? 🤔

To gain insight into your users' behaviour, you need to map their journey on your website or mobile app. This may entail examining user interaction details such as click events, searches, impressions, recordings, and more.

All this information needs to be stored somewhere, preferably in a data -warehouse like Redshift or Snowflake. This is where RudderStack comes in. ☄️

RudderStack has SDKs (iOS, Android, JS, Python, etc) which are used to send these events. You can set up a backend (either you can self-host or RudderStack can host it for you) which collects these events and then stores them in your data warehouse 🫙. Once you have the data, you can leverage RudderStack features to perform various operations on your data.

Let’s talk about the most important ones:

Features ✨

Profiles

Data is accumulated from various sources and dumped into the warehouse. These sources can be your website, mobile app, marketing platforms, sales engagements, etc.

All this data, generated by different users, are made identifiable. Users can be identified by associating identifiers like email id, phone no, username, etc. Sometimes you may need multiple identifiers to distinguish between the same user for work and personal email access.

Since all this data is spread across multiple tables within a warehouse, making sense of it is cumbersome and an error-prone task.

Therefore RudderStack provides you with profiles. With profiles, you no longer need to run complex SQL queries. Instead, you get a unified 360-degree view of a user’s journey across your product(s).

User Identification

So last we talked about identifying users, but how do you go about implementing that in RudderStack?

Simply, by using the identify call. It allows you to record traits about a user like his email, username, phone, etc and associate it to their actions.

This means that you should make the identify call after a user signs up for your product or logs into his account or updates his information. This way, you can record the trait with the action to identify them later.

But that's not all 👀

RudderStack also allows you to track visitors (not a customer yet) on your website by assigning them an Anonymous ID (anonymousId). Such an id can be a session ID corresponding to the visitor’s session.

Later, it helps you to turn these anonymous users into known users when they register for your product, thereby giving you the full view of a users journey - right from the time they visited the website to the point of conversion and beyond 🤯

Data governance

Events are generally created in a specific format that can include:

• Event type (button click event, page view event, etc)

• Event properties (version, page, timestamp, etc)

• Event metadata (option clicked, text copy, etc)

Now since you’ll be generating hundreds of these events across your product, you need to maintain consistency while creating these events. Depending on the scale of your organisation, there might be multiple stakeholders who define and implement these event specifications. 👩🏼‍🎨👨‍💻👩🏼‍🎨👨‍💻

This can lead to formatting inconsistencies that can be introduced in your data. Such inconsistencies can be missing fields, incorrect capitalisation (lowercase/uppercase) of event names or unit errors (pounds, dollars), etc.

RudderStack data governance API was created to address these data inconsistencies. It helps you to zero in on these inconsistencies by giving you access to information on all your events and their related schema. This way, you can implement processes to set alerts (🚨) for all possible errors that can happen in a particular workflow. Eg: Create alerts for incorrect capitalisation, missing data type, etc.

Integrations

You often want to send a subset of your data to other 3rd party websites. An example use case can be using Mailchimp to send automated email campaigns. RudderStack forwards these events so you don’t have to deal with 3rd party libraries or wrangle with their SDKs.

Transformations

Now that you know the possibility of integrating with 3rd party apps, let’s see the power of transformations. 💪

Transformations help you to write custom functions that transform your data before routing them to their destinations. There are several use cases where logic plays a crucial role, such as filtering to ensure that events are routed to the correct destinations, cleaning data, or enforcing data privacy through masking operations.

On top of that, transformations help you to connect to internal databases and enrich your user profiles for better analysis. They also offer a templates section that will get you started.

RudderStack 🆚 Segment

• RudderStack is open source, allowing you to keep total control of your data. With Segment, 👎 , everything is with them.

• RudderStack can turn your warehouse into a data source for the rest of your stack. Send enrich data to any destination.

• RudderStack pricing is based on events. Whereas, in Segment, you are priced on monthly tracked users

• RudderStack also comes with added advantages by offering reverse ETL support, dedicated VPC hosting, session tracking and automatically building a customer data lake.

Growth over the years 📈

Starting in 2019, RudderStack has come a long way. Its pivotal entry in the dev tool space was through being an open-source alternative to Segment. Post garnering interest, RudderStack raised its $5M seed led by S28 capital in 2020.

Fast forward, they’ve raised their series A and series B at $21M and $56M respectively and now have opened offices in India and Greenville. Reportedly, their revenue has also grown by almost four and a half times as their customer base is growing exponentially.

The Team 👨‍💻👩‍💻

The core team is a heavy mix of professionals who had already dealt with data on a large scale.

The ship is captained by @soumyadeb_mitra, who has a PhD in database systems and was a Sr. Director at 8x8 post his previous startup acquisition (MairinaIQ) by the same company.

This is followed by @sumanthpuram, who is one of the core engineers at RudderStack since its inception. Current VP of Engineering, Sumanth was previously Co-founder & CTO at Code Astra, a mobile and web development agency.

We also have @brianylu who is the Director of Product at RudderStack. He has played a couple of cameos at big names viz DoorDash, Dropbox and Google. He also does a newsletter - This Week in Data - which you must check out.

Getting started 👉 3 ways

• Docs: Study their open source and managed offerings to get a feel of the product.

• Schedule a demo: Have a custom use case? -> Talk to one of their solution engineers.

• Migration Docs: RudderStack has dedicated guides to help you migrate from other platforms (eg: Segment, Snowplow or from RudderStack self-hosted to RudderStack Cloud).

Author's Message

Open source is still nascent and needs more exposure, especially among companies still locked in the depths of commercialised software.

This is why I create bi-monthly, in-depth blog posts about open-source dev tools that catch my eye. By doing so, I hope to help companies save money, potentially hire new staff, and increase the revenue of deserving products.

If you love my content, do give me a follow on Twitter (I speak my mind there) or connect with me on LinkedIn.

GraphQL vs REST: Which API Type is Right for Your Application?

Mufassir Kazi — Thu, 19 Jan 2023 14:48:20 +0000

REST and GraphQL APIs are the developer's top choices for API design. With conflicting opinions on the internet, it's easy to get lost when debating which API type would make the most sense for your application.

Before we do a deep dive, let's have a look at some of the common terminologies used while discussing APIs:

Resource
It is the basic building block of a RESTful service. When you pull information from a server (backend) to display on the client side (frontend), you are essentially fetching a resource. There are various HTTP methods (next point) you can perform on a resource.

Eg. For an airline platform, flight_name, flight_details, and no_of_passengers for a flight are examples of a resource.

GET /flights/today

Response:

{
  "flight_name": "Airbus D-545-341",
  "flight_details": { 
    "flight_name": "Hawaiian Airlines",
    "flight_number": "N324KS",
    "flight_to": "Los Angeles"
  },
  "no_of_passengers": 284,
  "time_of_departure": "730 PM GMT"
},
{
  "flight_name": "Airbus D-325-536",
  "flight_details": { 
    "flight_name": "Hawaiian Airlines",
    "flight_number": "L5DFD",
    "flight_to": "Los Angeles"
  },
  "no_of_passengers": 281,
  "time_of_departure": "530 PM GMT"
},

  // ... more fields here

HTTP methods:
Below are listed some of the most common types of HTTP methods.

GET: Used in read-only mode, GET is the most common HTTP method. It is used to get a representational view of a resource's existing content.

POST: This method enables developers to create a new resource. The data to be sent to the server is given in the request body.

PUT: Updates / replaces all the existing resource's content. The new data is sent in the request body to the server.

PATCH: Though not commonly used, PATCH, like PUT, updates a resource's content but just partially. To simply put (no pun intended), it modifies an existing resource.

DELETE: It deletes a resource.

Data fetching
As the name suggests, data fetching is fetching data from the server to display on the client. With REST, it introduces drawbacks like "overfetching" or "under fetching". GraphQL, on the other hand, uses a query based approach which mitigates these drawbacks (more on this later).

Caching
It is the process of generating a cache which stores a subset of a data. This data then can be served up faster during future requests as they are already prefetched.

What is a REST API?

The successor of SOAP API, REST is a flexible, scalable, and easy to use architectural style. It was introduced as a simpler way to do server side communication.

A typical structure of a REST API consist of an endpoint, HTTP method, header and body.

An endpoint includes the URL of a server or service that helps to identify the resource to be fetched.
You can specify the type of request that is to be sent to the server by using the HTTP methods described above.
Headers are useful to provide information like caching, authentication tokens, etc to the client and server.
The body consists of payload / information that a client wants to send to the server.

Okay, what is GraphQL then?

GraphQL uses a "query" based approach where you execute queries in a single request. You do not target different endpoints, instead, you specify what you want in the request body. The content inside the request body is in the form of GraphQL query which is parsed on the backend.

This is a standardised approach and therefore there are rules defining how it should be parsed and what commands one can use, similar to how you would query a database.

The declarative vs imperative approach

Think of it this way - You are at a grocery store going through your shopping list and self guiding yourself based on signs at end of each row. You find the items you need, fill your cart, then continue to checkout. It's imperative because it requires you to know where all items are stocked up. REST approach is similar. You have endpoints and you fetch resources from these different endpoints to source your app.

GraphQL, on the other hand, follows a declarative approach. It's more like you have a personal assistant who goes and picks all items for you. The only thing you need is to 'declare' the items you need.

Why not to REST

1. Data fetching (again)
As discussed previously, REST API has a drawback of "underfetching" and "overfetching". Taking our airline platform example from earlier, suppose you only want details of all flights scheduled for the day.

In case of REST, when you hit the endpoint /flights/today, instead of just returning the flights information, it'll also include all other information that the endpoint has to offer i.e noOfPassengers, timings, airlineInfo, etc. This idea of fetching more information than necessary is termed as "overfetching". Vice versa, "underfetching" is when the request doesn't return adequate information requiring you to make multiple calls on different endpoints for different resources.

In case of GraphQL, you use a single request that can access data from multiple sources. Due to the query data structure, GraphQL allows you to precisely specify the type of data you want to receive from the server. This keeps your code concise and efficient.

2. Performance
Because REST has a drawback of overfetching, it returns a data set much larger than what is actually required. Of course, a lot largely depends on how the API is designed, but with REST, there is only so much you can specify.

For example, let's study the request below.

GET /dishes/details

This is an example of a REST call to get a list of all food dishes served in a restaurant. The data returned for a single dish is:

{
  "dish_name": "Apple Pie",
  "preparation_time": "170 mins.",
  "price": "$9.83",
  "ingredients": "2 1/2 cups all-purpose flour, 4 teaspoons sugar, 1/4 teaspoon fine salt, 14 tablespoons cold butter, diced, 1 large egg, 2 tablespoons freshly squeezed lemon juice, 3 pounds baking apples like Golden Delicious, Cortland, or Mutsu, 2/3 cup sugar, plus more for sprinkling on the pie, 1/4 cup unsalted butter, 1/4 teaspoon ground cinnamon, Generous pinch of ground nutmeg, 1 large egg, lightly beaten"
},

//More dishes here

The problem arises when you want only the dish_name and price property to be returned from the request. REST API doesn't allow you to extract specific properties from a given data set.

On the other hand, with GraphQL this is not the case. GraphQL API allows you to define the data you need and returns that only - no more, no less. This avoids a lot of unwanted data and the returned output is much smaller, thereby improving performance.

An example of a GraphQL query is as follows:

{
  restaurantDishes(limit: 3) {
   dish_name
   price
  }
}

And the response:

{
  "data": {
    "restaurantDishes": [
      {
        "dish_name": "Apple Pie",
        "price": "$9.83"
      },
      {
        "dish_name": "Fried Chicken",
        "price": "$29.99"
      },
      {
        "dish_name": "Cheeseburger",
        "price": "$1.39"
      }
    ]
  }
}

3. Schema and Type safety
GraphQL uses its own type system - SDL(Schema Definition Language). A schema defines how a client can access resources from the server.

This helps in catching errors easily while allowing the front-end and backend teams to work independently. GraphQL also allows you to stitch multiple schemas together so that a client can access data from different sources.

For REST, this would mean making multiple API calls at different endpoints. This can result in more computational power and lower efficiency.

4. Speed of Development
Because GraphQL allows you to specify the query on the fly, front-end developers can adjust response requirements without backend involvement.
Same is not true for REST though. REST APIs are structured according to endpoints and the data they return (e.g: /price, /ingredients, /dishnames, etc). To adjust response requirements, one may need to fetch data from different endpoints and be prone to the classic problem of underfetching / overfetching.

Problems with GraphQL

1. Learning curve
Despite its many advantages, GraphQL falls short on REST because of simplicity. If you're new to development, REST is much easier to learn between the two having no restrictions on what your resource can consume or return.

2. HTTP Caching
In REST, the URLs for the requests are different (GET, POST, PUT, PATCH, DELETE). This allows you to get a globally unique identifier for an object which helps you to implement an HTTP cache. This way, you can easily identify if two resources are same while also allowing you to avoid fetching the same resource twice.

Meanwhile, in GraphQL, you use a single endpoint. For non-mutable queries, the developer has to ensure that caching is setup manually and the correct key is being used to inspect the body elements. There are tools that cover GraphQL semantics, but most of them lack in things like mobile and browser caching.

3. Resource attacks
The most talked benefit of GraphQL allowing clients to query only the data they need comes with a huge drawback - performance. Open APIs used in an app do not allow you to control 3rd party client query behaviour. This can results in expensive join queries which can severely effect server performance, or worse, result in a DDoS attack.

4. Reporting (Errors)
As REST follows the HTTP spec, it allows many tools to probe a URL endpoint and study error messages if not OK. In GraphQL, these tools cannot help. GraphQL client errors always return a 200 OK status response with a Something went wrong message. As this is superficial, it is very difficult to handle and monitor errors on GraphQL.

Best practices to follow while designing your next API

1. Security first
All client - server communications should be protected by SSL / TLS. Your API should communicate over a secure channel thereby restricting users to only access information they requested and nothing more. Moving a step further, you can enforce a roles check for an admin role or have granular roles depending on your application.

2. Use nouns for endpoint paths
HTTP request methods are made up of verbs ( GET, POST, PUT, PATCH, DELETE). Adding another verb as an endpoint path will make your request difficult to comprehend. The action of the request should be defined by the HTTP method while your path can define the resource on which the action is being performed. Eg: You can make your routes self explanatory like GET/flights gets all the flights, DELETE/flight/:id is for deleting the flight matching the given id.

3. Control your data
As you scale, your data sets can get very large. Depending on the request, you might end up returning a large amount of data in a single request that will slow down your network and crash your systems. This is where filtering comes in. Allow data to be filtered and paginated so that in case of such a request, we return only a finite number of results at a time. This also helps in increasing performance and reducing server costs.

4. Versioning
Especially useful in public API settings, versioning allows your users to transition overtime to upgraded versions of your API changes (goodUX). Like most apps, you can follow the semantic version for versioning - eg: 1.0.4 indicates major version 1 and the 4th patch. This allows your users to keep using the older version in case they are not ready to upgrade or access the new release with the latest features. Also, this helps to avoid failure in third party apps that can still be accessing the older version of the API.

5. Caching
We learned earlier in the article what caching is and how it helps to improve performance of your system. However, there can be times when the data gets outdated. This creates issues in testing as we continue to see old data. To resolve this, you can use a caching solution like Redis or implement in-memory caching. This way, as your needs change, you can change the way your data is being cached.

6. Configuring your request and responses headers
This helps to specify information about the request being made. In return, it also specifies information on how a response was generated. Apart from this, you can also configure timeout settings to retry requests if they fail due to server or network errors.

Conclusion: Which API type will make the most sense for my application?

Honestly speaking, it depends on your application. Many times, instead of debating over REST vs GraphQL, a basic API for a basic site with focused endpoints would suffice (releasing the developer from unnecessary complexities).

That being said, REST is widely used for a simple reason: simplicity. Ground rule is if you don't have to combine data types in custom ways or are flexible in the kind of data your request returns, it's easier to keep things simple with REST. With REST, you can target a wide range of apps and users in the simplest way possible, especially when you don't know who or how your API is going to be consumed.

Meanwhile, GraphQL comes in the picture when you realise that you'd need multiple REST queries to perform a certain action. Instead of creating 10000 different endpoints to fetch minimised versions of your data set, use GraphQL to define what and how much of the data you need.

Ultimately, it all boils down to understanding your product and code architecture. As a closure, a well designed API is much important over the type of API that you end up using.

Hey there👋!

My name is Mufassir and I work as a Product Manager at a dev tool startup.

Thank you so much for reading till the end 💙. For reach-outs, I’m available on LinkedIn or feel free to follow me on Twitter.