Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add scripting layer in addition to liquid #1298

Open
onecreative opened this issue Nov 10, 2020 · 0 comments
Open

Add scripting layer in addition to liquid #1298

onecreative opened this issue Nov 10, 2020 · 0 comments

Comments

@onecreative
Copy link
Contributor

onecreative commented Nov 10, 2020

What if we had a highly performant coding language available to us as part of pOS?

Something like Go. And what if that made it so we could then separate our coding from our templating?

And as part of that, what if we could define our own globals that are processed before the first line of Liquid?

I imagine we could see not only massive performance benefits, but a healthy separation of concerns.

This thought is a result of a comment that Liquid is not a coding language, and my response that we use it as one. Both of those comments are correct.

Would this require a massive rewrite of the current system?

I don’t think so. Just introduce it as a globals layer. It’s something that runs before the first line of Liquid is processed. And it outputs the variables you’ll need in your Liquid.

No backwards compatibility issues.

We can even have it output to context.globals

For languages, perhaps Node is the best choice, just for familiarity. Not the fastest or the slowest either.

And this pre-rendering stage could be optimized independently of the liquid engine, resulting in a great speed advantage.

Would this give access to the servers?

No. This is still a layer.

Even Shopify has a concept like this.
https://help.shopify.com/en/manual/checkout-settings/script-editor

Does it give access to the database, etc?

Access is the same as it is in Liquid.

The big difference between is that liquid is a rendering layer, and this is a computing layer.

How will the two layers communicate with each other?

I’ve thought of two methods:

  1. A Globals feature that runs before the first line of liquid, and outputs as a liquid variable
  2. And tags in liquid which run scripts.

Like real functions.

The second is analogous to api_call: you call external service and then you are able to parse it’s response.

The difference being that you should be able to deploy and host those external services on platformOS

Performance

I probably don’t have to sell you on the performance benefits of pulling intense logic out of liquid.

There are many benefits, including being able to use official sdk for various services.

What are your thoughts?
I wonder how many custom liquid filters would start getting lonely if we did this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant