3 ms·

I am curious about your SDK now. Do you host it publicly? If no, could you at least explain what is the difference between your method and mainstream frameworks

I am curious about your SDK now. Do you host it publicly? If no, could you at least explain what is the difference between your method and mainstream frameworks?

jongjong 3y ago
I plan to introduce my SDK publicly via the no-code platform I've been working on as a 'low-code' alternative for cases were additional flexibility is required. To give you a rough sense: - My SDK has some front end components and back end components connected via WebSockets using a client/server framework I wrote years ago and have been maintaining. - It's all declarative so for example, for the back end, I don't write much code, I just declare the models, what fields they have, what views of the data are exposed and specific access controls. The back end is mostly a large JSON object. I don't want to go into too much details but the way it's set up, it's very flexible and you can model almost any kind of data and relationships with little to no code. It guides you towards a good architecture which makes good use of database indexing (so it performs and scales well). To connect the back end models and front end, it's a twist on the old CRUD concept so that it is conflict-free. I went down a completely different path to GraphQL and I think the result is simpler, more efficient, provides better access control, simpler caching and code (or should I say markup/JSON) is much easier to read and maintain. As you build your system using it, it guides you into making optimal architectural decisions at every step, keeping complexity as low as possible (as opposed to GraphQL which, by virtue of its extreme flexibility allows complexity to grow out of control). - The front end components provide ways to render lists and objects in complex ways (e.g. grouped, filtered based on relationships between different models; all declarative). Components are hooked into the model backend in a particular way so they update in real time by default. Real time updates are delivered to the front end efficiently. Only relevant components/views update themselves and they do so automatically. Pagination is automatic and specified declaratively as part of the HTML and in accordance to limits specified in the back end JSON. Access control is enforced automatically based on the rules specified on the back end in the JSON object. I'm almost at a point where I can build entire complex apps using only HTML on the front end and JSON on the back end with essentially no code.
- meiraleal 3y ago
  > I'm almost at a point where I can build entire complex apps using only HTML on the front end and JSON on the back end with essentially no code. I think you are missing the point of no-code. Your solution isn't even low-code, you just created a framework with well-thought components to start a project. If you need to integrate a third-party component that uses code, you'll need to integrate that code in your HTML/JSON or create a new abstraction in JS to use in the HTML. disclaimer: I'm creating a "similar" platform and got curious by what would set your SDK apart from mainstream frameworks but I don't think what you described is anything different. For the view part, is it using something like htmx, react or pure JS?
  - jongjong 3y ago
    It's definitely no code. I built some dynamic pages of my service to manage data with it that are all HTML markup and JSON. I would have used it for all pages if I had created the components earlier. HTML is markup, not code. JSON is object notation, not code. I used very little code to build my service. I think this type of highly flexible low-code is the right path to no-code. I know from experience that people with zero tech knowledge can be taught HTML and CSS in a few weeks.
    - perilunar 3y ago
      > HTML is markup, not code. JSON is object notation, not code. They most definitely are code. They are not programming languages, and writing them is not 'programming', but they are still code.
- HumanOstrich 3y ago
  You might find the paper Out of the Tar Pit interesting if you haven't already read it: https://github.com/papers-we-love/papers-we-love/blob/main/design/out-of-the-tar-pit.pdf https://github.com/papers-we-love/papers-we-love/blob/main/d... The ideas and approaches you talk about evoked some of the concepts from that paper for me. It talks a lot about separating accidental complexity and infrastructure so you can focus only on what is essential to define your solutions.

I am curious about your SDK now. Do you host it publicly? If no, could you at least explain what is the difference between your method and mainstream frameworks?

jongjong 3y ago

I plan to introduce my SDK publicly via the no-code platform I've been working on as a 'low-code' alternative for cases were additional flexibility is required. To give you a rough sense: - My SDK has some front end components and back end components connected via WebSockets using a client/server framework I wrote years ago and have been maintaining. - It's all declarative so for example, for the back end, I don't write much code, I just declare the models, what fields they have, what views of the data are exposed and specific access controls. The back end is mostly a large JSON object. I don't want to go into too much details but the way it's set up, it's very flexible and you can model almost any kind of data and relationships with little to no code. It guides you towards a good architecture which makes good use of database indexing (so it performs and scales well). To connect the back end models and front end, it's a twist on the old CRUD concept so that it is conflict-free. I went down a completely different path to GraphQL and I think the result is simpler, more efficient, provides better access control, simpler caching and code (or should I say markup/JSON) is much easier to read and maintain. As you build your system using it, it guides you into making optimal architectural decisions at every step, keeping complexity as low as possible (as opposed to GraphQL which, by virtue of its extreme flexibility allows complexity to grow out of control). - The front end components provide ways to render lists and objects in complex ways (e.g. grouped, filtered based on relationships between different models; all declarative). Components are hooked into the model backend in a particular way so they update in real time by default. Real time updates are delivered to the front end efficiently. Only relevant components/views update themselves and they do so automatically. Pagination is automatic and specified declaratively as part of the HTML and in accordance to limits specified in the back end JSON. Access control is enforced automatically based on the rules specified on the back end in the JSON object. I'm almost at a point where I can build entire complex apps using only HTML on the front end and JSON on the back end with essentially no code.

meiraleal 3y ago
> I'm almost at a point where I can build entire complex apps using only HTML on the front end and JSON on the back end with essentially no code. I think you are missing the point of no-code. Your solution isn't even low-code, you just created a framework with well-thought components to start a project. If you need to integrate a third-party component that uses code, you'll need to integrate that code in your HTML/JSON or create a new abstraction in JS to use in the HTML. disclaimer: I'm creating a "similar" platform and got curious by what would set your SDK apart from mainstream frameworks but I don't think what you described is anything different. For the view part, is it using something like htmx, react or pure JS?
- jongjong 3y ago
  It's definitely no code. I built some dynamic pages of my service to manage data with it that are all HTML markup and JSON. I would have used it for all pages if I had created the components earlier. HTML is markup, not code. JSON is object notation, not code. I used very little code to build my service. I think this type of highly flexible low-code is the right path to no-code. I know from experience that people with zero tech knowledge can be taught HTML and CSS in a few weeks.
  - perilunar 3y ago
    > HTML is markup, not code. JSON is object notation, not code. They most definitely are code. They are not programming languages, and writing them is not 'programming', but they are still code.
HumanOstrich 3y ago
You might find the paper Out of the Tar Pit interesting if you haven't already read it: https://github.com/papers-we-love/papers-we-love/blob/main/design/out-of-the-tar-pit.pdf https://github.com/papers-we-love/papers-we-love/blob/main/d... The ideas and approaches you talk about evoked some of the concepts from that paper for me. It talks a lot about separating accidental complexity and infrastructure so you can focus only on what is essential to define your solutions.