4 ms·

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

by mk0y 3y ago

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.

sisve 3y ago
Seems 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 ago
  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.
primitivesuave 3y ago
First 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 ago
    Pretty 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 ago
  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.
xonix 3y ago
Correct 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 ago
  A 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 ago
      MITM will see everything, but this should be the case with headers as well as GET params, passwords/tokens/data etc.
      - justsomehnguy 3y ago
        In 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 ago
I'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 ago
  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.

by mk0y 3y ago

sisve 3y ago

Seems 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 ago
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.

primitivesuave 3y ago

First 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 ago
  Pretty 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 ago
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.

xonix 3y ago

Correct 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 ago
A 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 ago
    MITM will see everything, but this should be the case with headers as well as GET params, passwords/tokens/data etc.
    - justsomehnguy 3y ago
      In 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 ago

I'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 ago
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.