mk0y

Built this in a day. Type natural language flight queries and returns real results. It includes Google Flights and Kiwi urls so far.

Stack: Next.js 16, Tailwind, OpenAI Responses API with native tools support, deployed on Cloudflare Workers.

First of all nodb isn't meant for really large scale applications. I will have to do a research on how to it best and simplest way possible. The idea behind nodb is simplicity - you start inserting data in no time. Indexing of what you talk about is currently not possible. I will definitely look into it though and restructure it if necessary. Thanks for elaborating and the feedback, much appreciated. I will post again when I have updates.

Yes exactly. One of the ideas was to share the API URL so you can use the same data somewhere else. I will also add the feature to have access token in the headers as well, since I've got feedback that it's not safe sometimes to have it in the query params. However, then you can't share it as a link.

Thank you, yes I see it exactly like that as well. In fact, I was in this situation over and over again, then had to do something about it. :D

I didn't work on mobile version yet, it's almost default Docusaurus installation. Thanks, will look.

I will see to change it to something else maybe. Thanks.

Thanks! And I fixed some bugs in the meantime. Yes, and the API should maintain its simplicity without making it super complex. And I'm still considering moving token to the headers instead of query params, as stated in one of the comments here. There are obvious pros and cons.

Yep, valid point. I made it to use in cloud functions, so I can store data somewhere. I didn't want to install Redis, or MongoDB for example, as my functions' dependencies.

Awesome. Nodb is indeed similar. What was itching me was to make an API through which I can store data. As I wanted to use it in cloud functions.

I'll definitely consider this and make a note.

Hey! Thank you for the feedback. Yes, it's very limiting (for now) since it's a free to use product right now. Indexing is done internally because the data model is arbitrary. This is key difference when we speak just about persistence. You will be making an app about groceries, someone else about movies. Indexing will be based upon your entities and sub-entity types.

Can you elaborate please? I'm not really familiar with webscale, so it's a No probably. :D

There's no export feature yet. It's a major feature to be implemented this summer.

Yeah, thanks, I'll look into it.

Actually feedback from non-tech folks (assuming you as such) is very welcomed, so thank you!

The product is at early stage and I will be adding more texts of all sorts (like disclaimers) and features. Data is truly not shared with anyone, it's in a dedicated server, but it's NOT in an encrypted database for now. It will be when it's developed.

All that is collected from users is their email address, since you can sign up using Google and Github auth only. Behind this auth one can create apps, environments and access tokens. Afterwards, requests to the API are open under access token.

Product is free for now, thus no pricing info at the moment.

Thank you. You're right it's overcrowded. I had passion to make it to use for my projects. I didn't want to install "npm install some-db", since I can't use persistence in cloud functions that way. Solutions exists like supabase, however I imagined separation of concerns as in apps/environments like in standard software projects beneficial for my use case.

Hi, i'm new to HN and didn't find comments easily! Sorry for late reply.

Having them in the query params was intended for sharing indeed. I wouldn't expect someone using it on the frontend of course. I might switch to having them in the headers instead, as it was initially like that. Idea was to use the service with minimal requirements.

Tokens can be set as READ_ONLY, these tokens are only meant to be used with GET requests. So you can share the link to use in some other app for example. Again, headers might be better however we can't share them, i.e. simple copy paste.

Hi, I made the API which helps you with your serverless applications. There's no installation of packages, you store JSON via HTTPS.

It works like this, you go to the dashboard on dash.nodb.sh and create apps and environments. Then via API you can create your JSON models.

An API endpoint is split like this /{appName}/{envName}/your-model/:id/you-model/:id/...?token={accessToken} This way you can split your data between environments like "dev" or "prod". And every environment is protected by an access token which is generated by nodb when you create a new environment in the dashboard. Only apps and environments have to be created in the dashboard behind bearer token, but your JSON models are protected by access token, so you can call HTTP requests easily from your code.

I would like someone to share their thoughts on this, whether this would be useful when working on any app, web or mobile, or inside cloud functions. In the docs on docs.nodb.sh is described everything (so far) about the API.

I'm making a RESTful JSON API called nodb. It's for storing JSON data into the database via HTTPS only. Thus the pun, of course there is a database, but it's behind this RESTful JSON API, so you don't need to manage a database for your apps.

By storing JSON items through the API you're actually building your own API, because when you store them (via POST request) you'll create URLs for fetching them as well. I would like someone to try to use it for their side projects and test it for production.

Let me know please your thoughts what you think about this project and what could it have added, adjusted or removed. I have plenty of ideas right now, like joining tables through query params.