Nodb simply utilises REST API to store your app data in JSON format to the cloud. There is no dependency installation to your project. Ideal for serverless applications.
Hi all!
This is my first SaaS product ever. I decided to start working on it around a year ago while I was working on something else completely. What drew me to this conclusion is that whenever I wanted to start making an app or API, I stop at figuring how to store my data.
I know, I know, there are a lot of solutions around storage (persistence) to use when making apps, but they were mostly "heavy" in bundle size. If I want to use Firebase I "npm install" it and it comes with lot of learning curve as well. This is just an example.
With nodb I imagined that the API starts with your app's name (global name, like S3 bucket), then comes environment name (e.g. "dev" or "prod"...) and then nested objects which I call entities. So, it looks like this:
/my-app/env/fruits/:id/varieties/:id...
Content type is always JSON so you don't need to specify it when making requests.
App name, env name are protected with an access token which you generate in the dashboard. You sign in to dashboard via Google or Github authentication.
Custom querying is described in the docs and I plan to add a lot of new query sets, including union of multiple entities. Additionally, I will make data types so you can optionally store typed JSON data. Dataset results are always paginated.
There's no dependency added to your project. You only make HTTP requests. This can be ideal for serverless applications, as you can't use external packages inside cloud functions for example. Supported methods are GET, POST, PUT, PATCH & DELETE.
There's (for now) limitation set to 100k read requests per month and 2k write requests. Nodb is currently free to use and I'd like to build an audience, so that we can decrease limitations significantly.
Report
A huge congratulations to you and your team for the successful launch of your product. Your hard work and dedication have paid off. Well done!
This is really neat, could potentially use it as a lightweight CMS! how could we limit the number of hits returned per query?
Also, curious about what use case you had in mind while building it?
@nitish_r_ Thanks a bunch! And yes, indeed it can be. By number of hits you mean paginated result? You can use __per_page and __page query params. It's documented in the docs as well. Let me know please if that's what you asked.
About the use case, I was actually building a Flutter mobile app. And I was using Firebase. But I didn't need the whole plethora of APIs provided by it, only to query data, as I didn't need real time updates either. Back then I didn't see mature solutions that will help me build the app. And Flutter was quite new. So, I guess one use case might be if there's a new framework on the horizon you can use nodb since hitting http requests will always be "for free", i.e. at the beginning we won't have (stable) libraries built for it just yet.
@mk0y8 not pagination, limiting total items returned per query. If I have 4000 records stored but I only want users to be able to load up to 500 records.
Also, are there different admin tokens?
@nitish_r_ Hi Nitish, that doesn't exist, except to set `__per_page=500` query param. Concerning admins, there is only one for each account. I didn't make the feature to have multiple accounts. However, you can create tokens and share specific ones with specific teams/people.
@evanwherchek Right now it's for a single user (single sign-in) only. However, each environment and each token can be created for use for specific user/team. For example you can only grant READ_ONLY rights for a token. Or, make a specific environment for QA and give QA team access to work with, instead of production environment.
nodb
unloved
nodb
unloved
nodb
unloved
nodb
Crustdata
Pitch Deck Catch Phrases
Coatails
nodb