fpp VS sst

Strong recommendation for Xlights, I used to program patterns for my dreamcoat.

I started with a 3D scan of me wearing the costume using my wife's iPhone when the first version with LIDAR came out. After cleaning up the scan (iPhone 12 LIDAR wasn't the best quality) in Blender, I spent a good many hours in Xlights placing every single light at its correct 3D position using the imported mesh as a reference. Laborious work, but with all 1300-odd WS2811 LEDs mapped in all 3 axes, it makes for a pretty beautiful product.

Using Xlights is great. For open source it's pretty smooth. There's a small learning curve for the technology, but making sequences a strong resemblance to video editing. The project has frequest updates, I haven't seen any project-breaking format changes in the 3.5 years I've used it, and it's clearly maintained by people who use it. Push new rendered sequences to my FPP-running raspi on the costume through wifi then editing the running playlist through a web interface on FPP on the laptop is a dream.

If anyone's curious:

FPP: https://github.com/FalconChristmas/fpp

My dreamcoat sequenced to Holst's Jupiter: https://www.youtube.com/watch?v=ZWzdUJsAMa4&pp=ygUNbGVkIGRyZ...

Timelapses of me making the costume: https://www.youtube.com/watch?v=PODWVIsqwwA&pp=ygUNbGVkIGRyZ...

I run my Christmas light show software (https://github.com/FalconChristmas/fpp) with a Pi: https://www.youtube.com/watch?v=vlxaA-ca6S0 :)

I use Falcon Player to run my show. This is software running on a Raspberry Pi that I upload my songs and light sequences to from xlights. FPP is configured to know where each light is plugged into on which pixel controller (small lighting computer). These controllers sit on my network and FPP pushes the data to them to play the songs/light sequences.

I recommend you to use a known working controller like this: the protocol is known (sufficiently reverse engineered ) to make it do anything you like. Tools like xLights and FPP can send data to the card and thus to the LED matrix.

You could also go the way of the LED panels (search for P5 Outdoor LED Panels) plus a Colorlight 5A 75B to control them. xLights and FPP support them well.

I don't think you need that much for it to work. I've seen so many cool light shows synchronized with music. You can use a Raspberry Pi and install on it Falcon Player ( FFP ) and connect everything through a network and maybe try on your laptop / pc a program called xLights to make some interesting stuff.

Details are here https://github.com/FalconChristmas/fpp

Happily! I will share what I use - please be aware there are lots of options in the space. Also, including my wife's advice from last year: Start small - one or two props can be make a great show and can be accomplished in a reasonable time frame.

Xlights: Sequencing and Scheduling software. This is what tells your lights what to do. (https://xlights.org/)

Falcon Pi Player (FPP): This software runs on your controller - A raspberry Pi or a Beaglebone are quite popular. This is what you run your sequences on. In my case, I drive my lights directly from my Pi. (https://github.com/FalconChristmas/fpp and https://falconchristmas.com)

We see some great results from using these in conjunction with frameworks such as SST or Serverless, and also some real spaghetti from people who organically proliferate 100’s of functions over time and lose track of how they relate to each other or how to update them safely across time and service. Buyer beware!

> But if you have a sufficiently large enough API surface, doing one lambda per endpoint comes with a lot of pain as well. Packaging and deploying all of those artifacts can be very time consuming, especially if you have a naive approach that does a full rebuild/redeploy every time the pipeline runs.

Yeah, thankfully SST [0] does the heavy lifting for me. I've tried most of the solutions out there and SST was where I was the happiest. Right now I do 1 functions per endpoint. I structure my code like url paths mostly, 1 stack per final folder, so that the "users" folder maps to "/users/*" and inside I have get/getAll/create/update/delete files that map to GET X/id, GET X, POST X, POST X/id, DELETE/id. It works out well, it's easy to reason about, and deploys (a sizable a backend) in about 10min on GitHub Actions (which I'm going to swap out probably for something faster).

I agree with the secrets/permissions aspect and I like that it's stupid-simple for me to attach secrets/permissions at a low level if I want.

I use NodeJS and startup isn't horrible and once it's up the requests as very quick. For my needs, an the nature of the software I'm writing, lambda makes a ton of sense (mostly never used, but when it's used it's used heavily and needs to scale up high).

[0] https://sst.dev

We will start by building a project with SST that provisions an API Gateway, a Lambda, and an S3 bucket. Once implemented, we'll look into testing for concurrent write conflicts or exceeding capacity limits.

I recently deployed a node websocket server using the SST Service construct. Until this point my stack had been functions and buckets. While I had no users 😢, I also had no costs 🤡.

Most my personal and side-business projects have very spiky load or just low load in general. Because of that I love using AWS Lambda as my backend since it scales to 0 and scales to whatever you have your limits set at.

I use SST [0] for my backend with NodeJS (TypeScript) and Vue (Quasar) for my frontend. For my database I use either Postgres or DynamoDB if the fit is right (Single Table Design is really neat). For Postgres I like Neon [1] though their recent pricing changes make it less appealing.

[0] https://sst.dev

[1] https://neon.tech

Yup. Entire core business product for a succeeding startup, though it's a small team of contributors (<10), and a much smaller platform team. Serverless backend started in 2018. Been a blessing in many regards, but it has its warts (often related to how new this architecture is, and of course we've made our own mistakes along the way).

I really like the model of functions decoupled through events. Big fan of that. It's very flexible and iterative. Keep that as your focus and it's great. Be careful of duplicating config, look for ways to compose/reuse (duh, but definitely a lesson learnt) and same with CI, structure your project so it can use something off-the-shelf like serverless-compose. Definitely monorepo/monolith it, I'd be losing my mind with 100-150 repos/"microservices" with a team this size. If starting now I'd maybe look at SST framework[0] because redeploying every change during development gets old fast

I couldn't go back to any other way to be honest, for cloud-heavy backends at least. By far the most productive I've ever been

Definitely has its warts though, it's not all roses.

[0] http://sst.dev

Along the way, you find an excellent framework, SST. Which is much faster than CDK and provides a better DX1. Here is how you then define your MultiPipelineStack.

SST is a powerful framework that simplifies the development of serverless applications. It offers a straightforward and opinionated approach to defining serverless apps using TypeScript. Built on top of AWS CDK, SST handles the complexity of setting up your serverless infrastructure automatically. SST is an open-source framework and is completely free to use.

SST is an open-source framework designed to facilitate the development and deployment of Serverless stacks on AWS. It operates under the hood by integrating with Amazon CDK. However, its primary benefit is in allowing us to concentrate on creating resources using familiar languages like TypeScript, treating them as Infrastructure as Code (IaC).