Can anyone definitively tell me if websockets work through AWS ECS or not?
Discussion
Normally you'd deploy an AWS API Gateway service which exposes a websocket for external use. And you have you service (Lambda, ECS etc) behind that API Gateway.
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-overview.html
Nice, thanks!
So there is no way of using the ALB, it has to go through an API gateway?
This gives me hope, but I need to test it
Oh, just saw this note too late.
Yeah, give it a shot. There's always a myriad of options to implement things in AWS: from do-it-yourself all in VMs, throught Containers, and using the fully managed services
Well, you *can* build pretty much everything yourself in EC2 (VMs) or Containers. But the recommended approach (more scalable, secure, cost effective) is to use the various managed services: API Gateway, Dynamo, Cognito, Compute engine (Lambda) and what not.
Don't really know your exact requirement though. The above is the "generic" advice.. 😉
I'm just thinking about if I could offer a hostable version of Strom. Like Strom-as-a-service 😀 Strom + lightning node. Its would need incoming websockets for the charge points to connect to.
I'm probably thinking waaay too far ahead 🙃
I see. I just wonder if you truly run the whole "thing" (Websocket + Strom + LN node (presumably LDK/Greenlight/BreezSDK)
Strom is Typescript (I guess), and can run in AWS Serverless
https://aws.amazon.com/de/blogs/compute/building-typescript-projects-with-aws-sam-cli/
Websocket can natively be run via API Gateways
And I guess(!) also the Lightning part of the code can be run by one of the AWS services. Presumably also AWS Serverless, if just using Greenlight/BreezSDK (bit i might be wrong)
That would mean you can deploy the whole Strom-as-a-Service stack serverless, and when a new CP/CP operator comes along, you presumably just edit some config somewhere to register it, and provision its own Websocket
I want to offer different lightning backends for Strom in general: LND (for umbrel or voltage), LDK, CLN, LNbits, Breez/Greenlight. Kinda plug and play. For Strom-as-a-Service different backends options would require different fee models, hosted LND/CLN nodes being the most expensive.
But Strom itself is being written in Go, which I think also works with AWS serverless. It could work, though I plan to integrate nostr also, which would mean it's a websocket client listening for events...
Have to think about it more.
So: user scans & pays the unique lnurl-p QR of a Charge Point ➡️ the LN backend issues a "start the charge" command through a OCPP bridge software ("Strom") ➡️ the CP returns the payable amount via the OCPP bridge to LN backend, which issues an invoice to the users LN wallet , right?
Can't you just build an OCPP plugin ("Strom") for LNbits, to do all that??
LNbits already has most of the components you need:
- Accounts. Each CP operator get its own LNbits wallet ("account") where the can and and maintain their own CPs, through the OCPP plugin
- Lnurl-p/w functionality
- supports already every LN backend
- Accounting and Reporting
- SaaS deployment possible
The OCPP plugin would be reponsible to establish the websocket to each CP when a charge is initiated, and translate Lightning (lnurl) <-> OCPP commands.
Or What say you, nostr:npub12rv5lskctqxxs2c8rf2zlzc7xx3qpvzs3w4etgemauy9thegr43sf485vg