Electric Clojure: netwerk-transparant full-stack development

[terabyte]

Zijn hier al meer mensen die aan het experimenteren zijn met Electric Clojure?

https://github.com/hyperfiddle/electric


Het is een DSL gebaseerd op Clojure (dus functioneel programmeren) waarbij je als ontwikkelaar niet meer hoeft na te denken over het definieren van een API tussen front-end en back-end, omdat de compiler dit al voor je doet. Het is een voorbeeld van reactive-programming, maar dan netwerk-transparant (dit in tegenstelling tot React.js dat reactive programming doet, maar dan in de client).

Dat de compiler dit doet is een stap voorwaarts, want waarom zou je dit nog handmatig doen als de computer (compiler) dit beter/sneller kan? We programmeren toch ook niet meer direct in low-level machinetaal

Hier https://electric.hyperfiddle.net/ zie je een aantal voorbeelden, waarbij je steeds één stukje code ziet, dat zorgt voor twee artifacts: een stukje JS (voor de client) en een Java jar (waar de server in draait). Deze worden verbonden via een websocket. De code die je ziet in de voorbeelden IS de volledige business logic. In elk van de voorbeelden geldt dat de compiler de optimale communicatie tussen frontend en backend heeft afgeleid.
Dus het hele concept om een 'backend for frontend' te ontwikkelen krijgt hiermee een andere betekenis, omdat het voor je wordt gecompileerd.

Dit concept ken ik niet in welke JS framework dan ook. De theorie erachter is hier te vinden: https://hyperfiddle.notio...681a8452bb9c7a9f10f507991

Dus dit is absoluut next-level. Ik hoop dat jullie dat ook zien. Als iedereen dit concept begrijpt en toepast gaat de web-ontwikkel wereld er heel anders uit zien. Het bedenken, implementeren en testen van een API puur voor frontend-backend communicatie gaat gezien worden als een tijdrovende low-level activiteit uit het verleden.

[RobIII]

Zonder (vooralsnog) verder gekeken te hebben: klinkt als Blazor? Maar misschien zit ik er compleet langs hoor.

[ Voor 51% gewijzigd door RobIII op 01-03-2024 15:49 ]

[Bigs]

Interessant concept. In principe kun je dit soort dingen met Blazor, SvelteKit en Remix ook eenvoudig bouwen, alleen zit in Electric de server en client code zo te zien nog wat dichter bij elkaar. Dat gaat wel een stuk verder.

Wat is het build artifact van een Electric project precies? Worden je client functies gecompiled met ClojureScript en geserveerd door een server die ook de server functies bevat? En dan met een soort websocket verbinding ertussen zo te zien.

[ Voor 10% gewijzigd door Bigs op 01-03-2024 16:03 ]

[Verwijderd]

Maar dan werk je met sockets die een poort innemen, weinig request/sec.
Wel leuk dat je het in 1 bestand heb zitten, maar meestal zit er een verschil in frontend zaken en backend zaken. Dan is verschillende bestanden lijkt mij fijner. Daarnaast kies ik ook voor server sent events voor realtime updates, vanwege readonly. En dan http post /get / patch/ put vanaf de frontend om de daadwerkelijke data op te halen. De server sent requests packages niet te groot laten worden, liever alleen events versturen. Zodat de server het aan kan. Bij sockets heb je gelijk weer een rate limiter nodig.
De taal vind ik niet heel erg duidelijk.

[terabyte]

Verwijderd schreef op vrijdag 1 maart 2024 @ 19:14:
Maar dan werk je met sockets die een poort innemen, weinig request/sec.

het is horizontaal goed schaalbaar aangezien je normaal gesproken geen state in de backend-for-frontend hebt
Electric is bijzonder geschikt voor web-based applicaties, met veel interactie, lange sessies, lage latency bij UI acties, real-time updates.

Wel leuk dat je het in 1 bestand heb zitten, maar meestal zit er een verschil in frontend zaken en backend zaken. Dan is verschillende bestanden lijkt mij fijner.

Dat is een kwestie van code organisatie, staat los van Electric. Het is een functionele lisp dus je kunt functies maken en deze in aparte bestanden zetten, maar in principe geldt hier de denkwijze: je ontwikkelt business functionaliteit, dus groepeer je je logica daarop. Backend-frontend onderscheid wordt een technicality.

Ander voorbeeld: als je een multi-threaded app hebt, dan boeit het ook niet op welke CPU welke thread wordt uitgevoerd, dat is low-level.
Ander voorbeeld: mensen die een taal zoals coffee/Typescript gebruiken, kijken ze echt naar de gegenereerde JS?

Daarnaast kies ik ook voor server sent events voor realtime updates, vanwege readonly. En dan http post /get / patch/ put vanaf de frontend om de daadwerkelijke data op te halen. De server sent requests packages niet te groot laten worden, liever alleen events versturen. Zodat de server het aan kan. Bij sockets heb je gelijk weer een rate limiter nodig.

Het lijkt erop dat je blijft hangen op het bezwaar van de websocket, maar dat is een implementatiedetail.

In combinatie met Rama https://redplanetlabs.com/docs/~/index.html#gsc.tab=0 kun je heel ver schalen

Zie bijvoorbeeld deze Kahoot kloon/PoC op basis van Rama en Electric:
https://github.com/jeans11/demo-rama-electric

Zelf http post/get/etc doen is precies wat Electric juist vervangt door een compiler, dus hier zeg je dat je eigenlijk tegen het hele idee van Electric bent

De taal vind ik niet heel erg duidelijk.

Het is een lisp. Met een goede editor kom je een heel eind.

[terabyte]

Bigs schreef op vrijdag 1 maart 2024 @ 15:58:
Wat is het build artifact van een Electric project precies? Worden je client functies gecompiled met ClojureScript en geserveerd door een server die ook de server functies bevat? En dan met een soort websocket verbinding ertussen zo te zien.

in de OP schreef ik dat er twee outputs zijn: client (JS) code en backend code, maar in werkelijkheid is er één artifact, namelijk een JAR waarin een Jetty server ingebakken zit die alle gegenereerde JS serveert + index.html maar ook de backend logica bevat (andere kant van de websocket)

zie bijv Deployment example: https://github.com/hyperfiddle/electric-starter-app

[Lisper]

Ja ik heb hier al mee gespeeld, ik vind het een zeer innovatief project, het maakt het hele onderscheid tussen frontend en backend een stuk kleiner.

In mijn ervaring zijn frontend end backend toch sterk gekoppeld, dus ik vind het een groot voordeel om alles op 1 plek te hebben, je kan zelfs binnen een functie client en server code mixen.
Geen gedoe met backend-for-frontends en REST, het is even wennen maar ontzettend productief.

Ik denk wel dat Electric Clojure meer geschikt is voor hele dynamische webapplicaties, voor voornamelijk statische site is het overkill.

Rama is ook erg interessant, beetje vergelijkbaar idee, maar dan voor data processing.
Met rama heb je je databases, message queues en processing logica op 1 plek, wat ik een enorm voordeel vind. Bij Rama is er wel een learning curve om de DSL te leren, en het is helaas geen open source.


Kwa duidelijkheid: ik vind Clojure goed te lezen, het is een kwestie van wennen aan een lisp. Maar ik was al bekend met Clojure en andere fullstack frameworks in die taal, zoals Fulcro.

@terabyte gebruik je dit op werk, of voor de hobby?

[ Voor 6% gewijzigd door Lisper op 05-03-2024 10:00 ]

[terabyte]

Lisper schreef op maandag 4 maart 2024 @ 12:33:
@terabyte gebruik je dit op werk, of voor de hobby?

Ik ben nu lokaal aan het experimenteren, maar bij vorige opdrachten waar ik aan web apps heb gewerkt zou dit heel veel problemen schelen en heel veel complexiteit wegnemen. Ook zou met minimale effort de UX een stuk beter zijn. Bijv. real-time updates, ook als andere gebruikers iets aan dezelfde entiteit wijzigen. Dit krijg je gratis met Electric. Ook het niet zelf hoeven te bedenken van een (REST) API voor de frontend zou heel veel ontwerptijd, implementatietijd, en testtijd (+ bijbehorende onderhoud) schelen, dus veel business benefits.