WolfOliver
Show HN: Open sourcing MonsterWriter, piece by piece
Show HN: Open sourcing MonsterWriter, piece by piece
Open sourcing MonsterWriter, piece by piece
Show HN: Declarative-forms – await an object the way prompt() awaits a string
Show HN: Declarative-forms – await an object the way prompt() awaits a string
Show HN: Declarative-forms – await an object the way prompt() awaits a string
Show HN: Build SaaS Applications Without Writing Back End Code [video]
Show HN: Build SaaS Applications Without Writing Back End Code [video]
Show HN: A Back End You Can Call Directly from React – No API Required
Show HN: A Back End You Can Call Directly from React – No API Required
Show HN: A Back End You Can Call Directly from React – No API Required
Show HN: A Back end-as-a-Service for collaborative SaaS applications
A back end where you never need migrations or auth code
They are enterprise customers but I see a lot of use cases where the end user is private person. From what I understand the recurring pattern is: A private person stores data and then specifies who can access this data. Mostly the amount of data records per person is quite small, so the discovery of the records is not that sophisticated.
I think where linkedrecords might be better suited are groupware apps like notion, google docs, airtable, github, where a group of people collaborate on the same large body of data records.
But I might not have understand SOLID 100% ...
The initial idea for linkedrecords was: I never want to write backend code and I want to build real time collaboration app. The realization that this way the user can choose its own backend came later. The idea never made it into MonsterWriter. But it would be very simple to add.
So the current implementation of MonsterWriter just hard codes the linkedrecords backend instead of prompting the user to pick one.
It was a public API without authentication. Everybody could upload a blob and received an access and encryption key which the client can use to access this particular object. The the client could also trigger a job using the data and producting an outcome. The outcome could then be downloaded and decrypted by the client with the keys.
While linkedrecords is the BaaS part of serverless DJAPI was the FaaS part of it. I've used DJAPI to upload LaTeX files and create a PDF out of it. The actual plan is to merge those projects at some point.
You can go to https://monsterwriter.com/ and see the system in action. When you click on login you will be redirected to a login provider, which in case of MonsterWriter is auth0. But it could also be an open source (e.g. KeyCloak) or any other commercial OIDC provider. Then it is up to the OIDC provider to display the "login with Google"
The hello world example on the website provides a dummy OIDC provider, If you try out the hello world example I guess this is the best place to really get an idea: https://linkedrecords.com/getting-started/
Maybe it is not as big of a problem as pirating the app would be against the companies SLA and serious businesses who pay the most money would just not do it.
But yes, it is a open point.