mvila

In 2023, when I think of "word processors", I think of them like Notion. When I think of "spreadsheets", I think of them like Airtable. And when I think of "to-do lists", I think of them like Basecamp's to-dos feature.

Also, since the SaaS platform will support document embeddability natively, we may end up with something that could replace Notion, with the advantage that embeddability will be possible with any document.

Regarding the fact that many companies pay for Google Workspace or Microsoft 365 to get emails, I believe that may change in the future.

The SaaS platform will provide powerful communication abilities to unify emails, Slack-like apps, and document comments.

Sure, emails will not disappear in one day, so we are considering offering email addresses as a gateway to the platform communication system.

Thanks, Jake, for your comment.

Here's what we have in mind about onboarding customers and developers.

The potential market is as large as the app market (B2B and B2C), but we will target small businesses at first and progressively expand as follows:

1. Small businesses

2. Mid-size companies

3. Large enterprises

4. Individuals

As with any new app platform, we will face the chicken and egg problem. We will need apps to attract users, and we will need users to attract apps.

We plan to solve this problem by creating the basic apps of any productivity suite (word processor, spreadsheet, to-do list, etc.) to enable us to get a first base of users.

Then, we will put much effort into "developer evangelism", providing quality documentation, tutorials, blog posts, videos, and direct communication to convince app vendors to join the platform.

We are not naive and know how difficult it is to disrupt a market. So, thank you for wishing us good luck! :)

TLDR:

The SaaS model offers many benefits and is undoubtedly the future of software.

However, when we moved from the good old desktop app to the SaaS apps, we lost a crucial component — the platform or operating system, such as Windows, macOS, or Linux — that was providing the ability to gather, among other things, the members and documents of an organization.

Therefore, we need to build the missing SaaS platform, which will require critical shifts in the following fields:

• Architecture: SaaS apps have to be constructed differently.

• Economic: SaaS vendors must change how they charge their customers.

• Standardization: An open standard is required so users and organizations cannot be locked into a platform.

Sure, it's challenging, but we believe it's the path to sustain the SaaS model.

@pc86 Please read the rest of the article. :)

Hi, everyone!

I have been working on Liaison for a year and a half with an obsession — simplifying full-stack development as much as possible.

Typically, a full-stack application is composed of a frontend and a backend running in two different environments that are connected through a web API (REST, GraphQL, etc.)

Separating the frontend and the backend is a good thing, but the problem is that building a web API usually leads to a lot of code scattering, duplication of knowledge, boilerplate, and accidental complexity.

Liaison removes the need of building a web API and reunites the frontend and the backend in a way that you can experience them as a single entity.

On the frontend side, Liaison gives you routing capabilities and object observability so that in most cases you don't need to add an external router or a state manager.

Last but not least, Liaison offers a simple but powerful ORM to make data storage as easy as possible.

Please check out the website, have a look at the documentation, and tell me what you think.

Any Node.js environment can run the backend. As for the database, Liaison supports only MongoDB for now, but more databases are expected to be supported in the future.

Interesting! It seems that both spelling are actually used...

In a nutshell:

- The frontend is "inherited" from the backend so there is no need to build an API server and an API client.

- The database is abstracted away by an ORM.

- The user interface can be encapsulated into the domain model.

If you are interested, you can read this article for more details: https://dev.to/mvila/full-stack-development-should-be-easier...

Thanks, exolymph. I thought so. I guess the "i" after "lia" seems a bit weird in English.

By default, nothing is exposed. To make an attribute or a method accessible from the frontend, it must be explicitly exposed by using the `expose()` decorator.

Liaison doesn't expose anything by default. Only the allowed attributes and methods are exposed.

Liaison allows inheriting layers from each other. So, you can easily separate your API layer with your model layer, and you don't need to build a web API for that.

About API versioning, the problem is the same as any web API. It's possible to add backward-compatible changes, otherwise, you need to fork the backend into a new endpoint.

About interoperability with non-JS environments, I wrote an article about that: https://liaison.dev/blog/articles/How-about-interoperability...

I wish that too. :)

Liaison has nothing to do with a backend-as-a-service. You can host your backend anywhere you want.

About authorization, Liaison doesn't expose anything by default. Only the specified attributes and methods are exposed, and there is an authorization mechanism so you can customize what you want depending on the user.

For now, Liaison is JS-focused. So both the frontend and the backend have to be implemented in JS.

But the communication protocol (https://deepr.io) in between is language agnostic. So it is possible to imagine Liaison being ported to different languages in the future.

Your point is valid, but Liaison allows you to build different layers if you wish.

If you worry about cluttering the business logic and want to clearly separate the exposed API, you can expose subclasses of your domain models instead.

I don't understand why it is wrong to use CDNs to distribute common libraries.

About the fact that I have used Liaison to build its own website, I agree that it might not be the best choice. :)

For now, Liaison doesn't support server-side rendering, but it is something that could come eventually.

This has nothing to do with JSON RPC. Liaison uses Deepr (https://liaison.dev) as a communication protocol.

Regarding the number of XHR calls, to be accurate, it is not 6 but 4. Once Liaison is complete and optimized, the number of calls should drop to 2.

Also, please keep in mind that Liaison is made for building single-page applications. So, using it for a simple blog might not be the right choice.

And about your security concern, please head over here: https://news.ycombinator.com/item?id=21660785

For now, with Liaison, API versioning is no different than usual: preserved endpoint for backward-compatible changes and new endpoints for breaking changes.

A Liaison backend is stateless, so there is no shared state to worry about.

Please see my answer here: https://news.ycombinator.com/item?id=21660785

For now, yes. Liaison is implemented in JavaScript, but the communication protocol (https://deepr.io) is language agnostic. So it is possible to imagine Liaison being ported to any languages in the future.

A Liaison backend is stateless, so there is no shared state or garbage-collection to worry about.

By default, a Liaison backend doesn't expose anything to the frontend. For a method (or an attribute) to be exposed, it must be explicitly declared as such.

Here they are: https://npmaddict.com/#/feeds

Yes, it is definitely on the to do list.