Earlier quoted context omitted.
Admittedly, yes. This is the massive appeal of Mongo et al., or just JSON[B] columns in an RDBMS. Unfortunately, at a very deep level, that’s simply not how RDBMS works. The tuples are a B+tree, and in some (MySQL [InnoDB], SQL Server) cases everything is clustered around the PK. If you don’t create a data model that’s easily exploitable for optimizations designed around that data structure, you’re gonna have a bad t…
Nosql doesn't solve the schema migration problem. It just means you don't formalize your schema. But your code will implicitly require a certain schema anyway. Changing the schema means changing the code and migrating data. You'll have to write migration scripts and think about backward compatibility. Same problems as in sql.
Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
241–250 of 269 posts
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#242Really liking it so far! An offline-first platform that lets you store your information in a central way and provides multiple forms of use and access is exactly what I've been trying to find, without much success until now. I'm not sure I've understood how to fully realise the promises of it though. I created a board, and added some records to it, alongside fields for additional data. It's not obvious to me how to u…
You raised an issue that I plan to fix soon. Currently certain fields (i.e. time range) only show on specific modules (i.e. calendar) but I'm planning to allow them everywhere. Could you share your use case on embedding a single record? I disabled that for now because I imagined people would usually embed all records together in a certain view. Hm I'll think about searching for blocks in autocomplete, or perhaps some…
Use cases for embedding a single record - in a bunch of kanban board use cases that involve shuffling a "unit of work" across various pipeline stages, I'd like for pages and blocks (discussion documents, etc) to be able to either link to that record (ideally with a link back as well) or be entirely represented by it. This speeds up workflow, and reduces ambiguity during communication. I'd expect, e.g. that one might create a Board representing a project and work to be done for it, and a Channel in which participants might want to write messages like "Do you need any help for @Task1 ?".
The offline mode bit - that's correct, I didn't open the other pages on my phone before going offline. I imagine it does come down a bit to what the overall impact on performance would be, but in terms of reducing the mental overhead of using a particular tool, having online devices completely sync means that if I close my laptop to jump on an underground train, I only need to quickly open my mobile app, wait for a "tick" to appear to indicate it's synced, then I'm ready (and importantly, I feel reassured that I'm ready). By contrast to the current system, I'd need to mentally try and keep track of which files I've edited recently, and which files I've already opened on which devices, and try and manually calculate what I need to open on my phone and tablet in order for me to not discover halfway through doing something on the train that I don't have access to the new resource I just made. It makes a big difference in terms of how much work and mental energy a tool is saving you, and how much it still requires of you.
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#243In the open source world, there is AppFlowy, Anytype, NocoDB, and APITable too so that's some strong competition. Is there a better argument for using your tool over one of those?
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#244Earlier quoted context omitted.
Admittedly, yes. This is the massive appeal of Mongo et al., or just JSON[B] columns in an RDBMS. Unfortunately, at a very deep level, that’s simply not how RDBMS works. The tuples are a B+tree, and in some (MySQL [InnoDB], SQL Server) cases everything is clustered around the PK. If you don’t create a data model that’s easily exploitable for optimizations designed around that data structure, you’re gonna have a bad t…
Yeh RDBMS is probably the wrong choice for most apps. It was good for crunching sales data in batches back in the day. Everything today is pipelines and reactivity. My dream is to have a tool to model my logical data model and then it will organize my data into the best storage and caches. I don't think any existing database today is useful.
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#245Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#246Earlier quoted context omitted.
You raised an issue that I plan to fix soon. Currently certain fields (i.e. time range) only show on specific modules (i.e. calendar) but I'm planning to allow them everywhere. Could you share your use case on embedding a single record? I disabled that for now because I imagined people would usually embed all records together in a certain view. Hm I'll think about searching for blocks in autocomplete, or perhaps some…
Thanks for the response :D Use cases for embedding a single record - in a bunch of kanban board use cases that involve shuffling a "unit of work" across various pipeline stages, I'd like for pages and blocks (discussion documents, etc) to be able to either link to that record (ideally with a link back as well) or be entirely represented by it. This speeds up workflow, and reduces ambiguity during communication. I'd e…
As for the switching to mobile scenario, it also makes sense. I'll think about this, it might be a button that allows you to "force sync" everything.
Thanks for the detailed explanations :)
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#247I tried to add/link a "List" item from inside a "Notebook", but couldn't find a way. Am I missing something or isn't it really possible?
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#248Single biggest thing you need to nail down fast: the data model. It is extremely hard to shift as things grow, and without careful thought, it’ll turn into a horrifying miasma of JSONB columns, duplicated data, orphaned rows, and garbage performance. Customers are going to store surprisingly large items in Docs, where you’d be tempted to inline them instead of offloading to S3 et al. Chat practically needs to be its…
The problem with modern development is having to nail down the data model first. I wish we would develop software where the data model could easily change. To do this every data dependency in the system needs to traceable. Nothing does this so far. And everyone just picks a database off the shelf but none are even remotely useful for this.
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#249As no one has asked so far, I’ll have to do it, how does this differentiate itself from Lotus Notes?
Re: Show HN: I made an app that consolidated 18 apps (doc, sheet, form, site, chat…)
#250Super impressive app by the look of things, but as you asked for feedback, it is (to me) very confusing on the product side of things (i.e. what is it and why does it matter to me). As a business user it's not clear how I would use it, and why I would care. Your front page reads as: > Nino is a collection of apps that can interoperate with each other on the block-level from one uniform interface. It has interoperable…
I totally agree. Coming across Simon Sinek's 'Start with Why' has helped me a great deal in communicating in general. Even in conversations this applies: https://www.youtube.com/watch?v=u4ZoJKF_VuA I also suggest reading his book. In terms of this theory you should communicate like this: Why, How, What You are starting from your 'What'. I haven't really grasped the core of your product, but to restructure it could be…
Thanks guys for the feedback. I think it's pretty clear what should be worked on next.