14 ms·
I made nodb, a RESTFful API to store and fetch JSON
- xwowsersx 3y agoSomething's up with your site on mobile. https://ibb.co/mT5hR3z https://ibb.co/mT5hR3z
- nazgulsenpai 3y agoLooks fine here: https://ibb.co/PtC1d7p https://ibb.co/PtC1d7p
- mk0y 3y agoYeah, thanks, I'll look into it.
- mk0y 3y agoHi, 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.
- sisve 3y agoSeems like a good idea. It would have been revolutionary 10-15 years ago. But the db-space has gotten really crowed the last couple of years. And all have the focus on doing it simpler. You should try to find your target audience and see how you can make nodb better then what ever db/solution that audience is using instead of nodb Good luck!
- mk0y 3y agoThank 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.
- primitivesuave 3y agoFirst let me say that the minimal interface you've designed for the dashboard is lovely. But also consider that as you talk to potential customers for this, the hardest sell is "send your data to a third party" and the easiest sell is "here is something that will save your developer's time". The biggest problem it seems like most people are facing now is getting their data transported between services.
- bjornsing 3y ago> The biggest problem it seems like most people are facing now is getting their data transported between services. Could you elaborate a bit?
- primitivesuave 3y agoPretty much every tech company is built on a stack of SaaS products (Google suite, CRM tool like HubSpot, etc), and it seems like a lot more innovation is going into integrating/standardizing their APIs. If you're just focusing on making a pure developer tool, a good example of successful execution is cronitor.io.
- mk0y 3y agoThanks! 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.
- xonix 3y agoCorrect me if I'm wrong, but to me passing the access token in the GET URL is not a good security practice. This increases the probability of unintentionally exposing the token. The URLs can be logged by proxy servers, application logs. Simply, user can accidentally send the link with token in chat, etc. Usually in REST APIs the auth token is passed via some HTTP header.
- dndn1 3y agoA stackoverflow answer on this: https://stackoverflow.com/a/499594 https://stackoverflow.com/a/499594 I don't think proxy servers or sniffers see GET data - it's encrypted, assuming HTTPS of course. Server logs might be an issue. Browser logs and accidentally sharing is definitely a bigger issue. Less of a concern if API is only used behind the scenes by apps though. Disclaimer: I'm not an auth expert!
- justsomehnguy 3y ago> I don't think proxy servers Proxies with MITM (mostly corporate) would see everything, because they are terminating client SSL/TLS.
- dndn1 3y agoMITM will see everything, but this should be the case with headers as well as GET params, passwords/tokens/data etc.
- justsomehnguy 3y agoIn case there is no MITIM but the original link was written using the plain HTTP then the proxy would see it anyway, before upgrading to SSL CONNECT.
- justsomehnguy 3y ago> Usually in REST APIs the auth token is passed via some HTTP header. Yes, headers or even as a data in the POST request. > Simply, user can accidentally send the link with token in chat, etc. Yep! Even more - it can be seen in the URL even if the user send a screenshot.
- bachmeier 3y agoI'm a little confused after looking at your website. You're expecting someone to give you their personal data, there's no pricing information, there's no way to get their data back, and since they don't know anything about you, there's no restriction on what might be happening to their data. What I've written may or may not be true, but I'd expect anyone looking at the landing page to want those things to be addressed. You might have more luck if you offer a self-hosted version that folks can run themselves, and then once they trust you and decide they don't want the admin burden, they can pay you. Disclaimer: I'm not your target audience, but I've investigated a lot of these services for my own things, and these are my feelings after an initial look at your website. I'd honestly not return for a second look under normal conditions.
- mk0y 3y agoActually 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.
- gregjor 3y agoWho do you target this for? Why would I use this instead of Redis, or any of the many open source and SAAS/IAAS key-value stores? I would want more control over important data, not pushing it unencrypted to an opaque service over HTTPS.
- mk0y 3y agoYep, 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.
- ralusek 3y ago> Number of write (POST, PUT, PATCH, DELETE) requests is limited to 2k per month Many production applications use substantially more than this in 1 second. I think even most people developing a project will exceed that limitation before even releasing it. You should put a disclaimer somewhere more obvious. Second note is, without indexing options, what's to distinguish you from S3, or Dynamo, or DocumentDB, or Mongo, or Rocks, Level, Foundation, Redis, Fauna, Postgres. JSON isn't enough, what's the hook?
- moneywoes 3y agothanks, did not see this but it saved me time
- mk0y 3y agoHey! 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.
- ralusek 3y agoThis is the case for every database, but they still tell me what indexing options I have available. With an RDBMS I know that I can use hash key indexes for fast lookups on an exact key. I can use B-Tree indexes for range or partial key lookups. For S3 I know that I can do exact lookups, or prefix scans, and that scans occur in ascending order, but cannot be done in descending order, etc. I know nothing of what lookup schemes are available to me in your application, and what kind of Big O profile to expect from each. It has nothing to do with whether it's a grocery app or a movie app.
- mk0y 3y agoFirst 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.
- zikero 3y agoSomething similar I'm working on: daba.so
- cornfutes 3y agoBasically, a directory tree where the files are JSON. Instead of Unix rm, ls, cat, echo/>>, we have rest endpoints. The main value prop of a DB is performance, moreso than the interface. How is this different from S3 or Firebase’s rest API? > Nodb can easily accommodate an increase in the number of requests without breaking down or becoming slow. Your app remains responsive and reliable, even during periods of high demand. From the limitations docs page: > Number of read (GET) requests is limited to 10k per month
- ashnehete 3y agoI'm assuming the limitation of 10K per month has more to do with their small cloud infrastructure budget than the actual database. Saying that, I can agree that intutively, a webserver can have slower performance than a traditional database but it would be interesting to see some benchmarks.
- throwawaaarrgh 3y ago> The main value prop of a DB is performance Filesystems are databases. Do we use filesystems because they're faster than doing direct i/o? There isn't a value proposition for databases, because a value proposition is a business statement. If there were a business statement for databases, it would be a management interface for data. Nobody cares if a database is fast, they care if they can get their data in and out easier.
- cornfutes 3y ago> There isn't a value proposition for databases, because a value proposition is a business statement. If there were a business statement for databases, it would be a management interface for data. This is just bunch of vacuous statements. Are you suggesting this product exists not to serve a business prop or value ? > Nobody cares if a database is fast Businesses do. There’s a reason people don’t attempt to build their own database. Every serious database meant for production use takes performance into consideration. People would just roll their own database otherwise, but we pile into Postgres, or even MongoDb, because they’re battletested and has had years of optimizations. More than half of the work in database implementations is in engine and query optimization. > they care if they can get their data in and out easier. Then just store and read flat files from disk. Strange to use a throwaway to make this comment. It seems like you are the author justifying a product that does need to exist.
- ulrischa 3y agoWould be better if I could self hostsuch thing
- mk0y 3y agoI'll definitely consider this and make a note.
- rajamaka 3y agoLooks very similar to my last project ddump.io that I got bored with and abandoned. Tried to value add here with a concept of sharable "social" API accessible JSON data like Pastebin.
- mk0y 3y agoYes 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.
- vivegi 3y agoIt is a minimal product. In order to be a minimum viable product certain features may be needed: 1. Some data reliability guarantees (eg. how does this compare with Amazon S3 [1] that provides 99.999999999% durability and 99.99% availability of objects over a given year)? 2. Backup and restore 3. User-generated keys to encrypt the data 4. User-specified indexing [1]: https://docs.aws.amazon.com/AmazonS3/latest/userguide/DataDurability.html https://docs.aws.amazon.com/AmazonS3/latest/userguide/DataDu...
- roqi 3y agoNodb's docs page is completely broken and unreadable in mobile. Not the best look.
- mk0y 3y agoI didn't work on mobile version yet, it's almost default Docusaurus installation. Thanks, will look.
- Takennickname 3y agoSo sqlite for nosql? That's super useful for prototyping. If it supports the same api as the major databases then this is a homerun.
- aw4y 3y agoDid something similar in the past: https://github.com/rehacktive/caffeine https://github.com/rehacktive/caffeine
- demarq 3y agoI’m happy someone is trying this. It puts back the focus on developing your app over being a database admin. When prototyping an app, this would be a biiiiig time saver!
- mk0y 3y agoThank 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
- bdcravens 3y agoCan be replicated using S3: https://docs.aws.amazon.com/apigateway/latest/developerguide/integrating-api-with-aws-services-s3.html https://docs.aws.amazon.com/apigateway/latest/developerguide...
- moneywoes 3y agoHow would I export this out of nodb if my project gets big? considering using this
- mk0y 3y agoThere's no export feature yet. It's a major feature to be implemented this summer.
- abarwick 3y agoI find monospaced font in documentation nearly unreadable for some reason.
- mk0y 3y agoI will see to change it to something else maybe. Thanks.
- nodesocket 3y agoI also wrote a dead simple bash, and very naive implementation of a JSON store (https://github.com/nodesocket/jsonlite https://github.com/nodesocket/jsonlite) which scratched an itch I personally needed a few years ago. To my surprise it seems like a lot of people were interested.
- mk0y 3y agoAwesome. 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.
- mikedelago 3y agoThis just feels like CouchDB or MongoDB but with extra steps
- tester457 3y agoI'm writing a small webapp and I'm hosting it on a PAAS which is stateless between deploys. I merely need to persist a single string between deploys, which gets changed when the app is running. And buying another service like S3, or hosting postgres or a databse is overkill. So this seems promising!
- WA 3y agoMaybe you need this: https://textdb.dev/ https://textdb.dev/
- tester457 3y agoThis is cool thanks!
- kqr 3y agoHuh, that is a very interesting problem to have. It's certainly not the scale or complexity or security or reliability requirements that make storing your data difficult -- it's the choice of hosting technology! That sounds dismissive but I don't mean it that way. I'm sure you've chosen wisely. I just find the problem intriguing because I don't know of any obvious solution and it's not one of the common problems people have with persistence. I'm trying to think of what sort of stateful servers you might be using anyway that you can piggyback for this. Some ideas: - SSH to any Unix box really - Email - Web-based pastebin service with an API - Regular Twitter tweets - Something stored on whatever you are using to conduct the deployment - An image uploaded to imgur where the image data are the string you need - DNS records - Any web service where you have a user profile editable through an API you could use one of the profile fields to store the string The list is getting more stupid as I go so I should probably stop there. But if you have written the service such that you can reject a deployment unless you're sure it worked, you are technically free to use quite stupid ways to store the data because worst case the deployment just fails and the old code chugs on.
- tester457 3y agoThanks for considering my problem intriguing. I didn't find your comment dismissive at all and I appreciate your thorough response. Also your ideas are interesting! The last one especially. > But if you have written the service such that you can reject a deployment unless you're sure it worked, you are technically free to use quite stupid ways to store the data because worst case the deployment just fails and the old code chugs on. I do and there's lots of error handling, so I'm not worried about doing a fun idea like editing a user profile via API. Your suggestions have my gears turning.
- pseufaux 3y agoHaving a really hard time not reading nodb as noob.
- chrisgd 3y agoIs this webscale? /s
- mk0y 3y agoCan you elaborate please? I'm not really familiar with webscale, so it's a No probably. :D
- throwawaaarrgh 3y agoI actually like this, because it gets much closer to a simpler, unix-y model of computing. No, this thing is not a good idea for doing anything complex. But sometimes you don't need complex. This seems to be about as simple as you can get. (Excepting that you don't need JSON at all to exchange key=value data over HTTP, as it already has multiple ways to pass key=value built into the protocol)