RVS_BlueThoth VS payload

I generally have a “What Problem Does This Solve?” section in my READMEs.

https://github.com/LittleGreenViper/LGV_TZ_Lookup#what-probl...

https://github.com/LittleGreenViper/LGV_MeetingServer#what-p...

https://github.com/RiftValleySoftware/RVS_Spinner#what-probl...

https://github.com/RiftValleySoftware/RVS_BlueThoth#what-pro...

https://github.com/RiftValleySoftware/RVS_PersistentPrefs#wh...

etc.

> I had one developer take 6 months to build a (relatively simple) top nav for a web app. This shouldn't have taken more than 1-2 weeks, even with a careful eye for detail.

Oh, you mean "bikeshedding."

Here's an example of the difference between basic quality, and High Quality:

If you look at most of the repos for SPM modules in my portfolio[0], you'll see that the vast majority have test harnesses. I prefer using test harnesses[1].

These test harnesses tend to be pretty damn robust apps. Many are "ready for app store" robust. A lot of folks would just publish them, "as is." I've been writing apps for a very long time. I'm fairly good at this.

I can write a fairly good test harness, with full app capabilities, in less than a day. If I take the time to localize it, maybe add a day or so.

Here's an example of some test harnesses[2]. Note that there are four of them. These represent the four different target environments for Apple (iOS/iPadOS, WatchOS, TVOS, and MacOS). I'll probably need to fork iOS and iPadOS, in the future, but we're not there, yet. A single codebase is still good for both.

They test a Bluetooth framework[3].

It probably took me around a week or so, to write each one. They are pretty damn good. I think they are all "App Store ready."

I decided to actually go ahead, and create a set of apps, based on these[4], [5], [6].

I spent well over a month, on each, after merging over the test harness codebases, to make them ready for the App Store. Lots of UX testing, removing code that only applied to testing, and adding "friendlier" user interface.

I'm working on an app that I started about a year ago. Actually, I started it over ten years ago, if you include the two servers that I wrote, upon which it depends.

One of the reasons that it has taken so long, is that I have truncated months of work, and tossed them in the garbage, because they were not the proper way to go. I have an "evolutionary design" process[7], that means this can happen. I plan for it. I've probably shitcanned three months' of work.

Another thing that I do, is have an "always beta" approach to Quality. I maintain the product at "incomplete, but ship Quality" status for as much of the project as possible. In fact, I've been sharing it with the team, using TestFlight, since Oct 3, 2020 at 7:47 AM (I got that from the TestFlight metadata).

That means that the app has been stable and robust enough for user testing, and approval for basic App Store release (TestFlight External Testing is a more relaxed standard, but try pushing out a crasher, and see how far that goes).

I add localization support, accessibility, Dark Mode support, leak testing, etc., at every turn. It's very useful, because I can solicit immediate feedback from non-tech team members. It also means that the "basics" for App Store release are constantly being tested and validated.

Even more useful, if we want to ask for money, it's dam easy. We just loop the person we're begging from, into the TestFlight External Tester pool, and they can run the app without a Marketing chaperone, or sacrifices to the demo gods. We can also get valuable feedback from them.

It's really, really nice, and it has been, for many months.

I feel like we are now at a "starting point." Even though it has been a fully-functioning, release-ready app for the last couple of months, it need the "MVP treatment," where the testing pool is expanded, and we start applying it to "in the wild" scenarios.

Lots of companies use their customers as guinea pigs for the first several releases; usually by shoving baling-wire-and-duct-tape junk down their throats (and making them pay for it), before hitting their stride. It's a deliberate strategy. Some months ago, I read a post, here by a founder, declaring that "if you don't get physically sick at the quality of the code in your MVP, then you are spending too much time on the code quality."

Basically, deliberately write garbage, and force it on your users.

One of the reasons that I took on this project, was the founder is a friend of mine. He is running it as an NPO (501c3), and putting his own money into it. He doesn't really have much of it, to begin with. Also, more alarmingly, he didn't actually have a particularly good idea of what, exactly, he wanted the app to be. That's a recipe for disaster.

He asked me to help him vet some development shops he was approaching, to realize his vision.

It was eye-opening. He got a number of ridiculous quotes. I know what is necessary for this type of project (not small). For example, when one said that they'll deliver a full multi-server, multi-client app for MVP in three months (firm), upon getting a vague, hand-wavy requirements spec, it was hard for me to keep a straight face.

After a few of these, I just got disgusted, and said "Screw this. I'll do it." I've been developing it for free, as a native iOS/iPadOS app.

He has to pinch himself.

[0] https://stackoverflow.com/story/chrismarshall

[1] https://littlegreenviper.com/miscellany/testing-harness-vs-u...

[2] https://github.com/RiftValleySoftware/RVS_BlueThoth/tree/mas...

[3] https://github.com/RiftValleySoftware/RVS_BlueThoth

[4] https://apps.apple.com/us/app/blue-van-clef-for-mobile/id151... (iOS -Includes Watch app)

[5] https://apps.apple.com/us/app/blue-van-clef/id1529005127 (Mac)

[6] https://apps.apple.com/us/app/blue-van-clef-for-tv/id1529181... (TV)

[7] https://littlegreenviper.com/miscellany/evolutionary-design-...

Despite being a relatively newer player, Payload's GitHub repository has accumulated 18.8k stars and 1.1K forks as of April 2024, reflecting its growing community. The project has also secured $5.6 million in funding, positioning it for continued growth and innovation.

My most recent project launched in January. NextJS 14 client integrated with PayloadCMS (http://payloadcms.com) for the back-end. I love both technologies in theory, but they're both going through a renaissance period and "bleeding edge" doesn't even begin to describe it.

If I'm just building a client app, create-react-app is still my go to.

Before now, I'd been building on WordPress for 10+ years for anything client-administered. Planning on using Payload from here on out.

Payload CMS: The Customization Insurgent

Payload is free, you can self host it without paying a one time fee or a SaaS fee for its use, it even says so at the bottom of the homepage

James, the co-founder of Payload, a headless CMS with MongoDB support, shared his insights on the drawbacks and limitations of using a headless CMS in the context of web development. He challenged the promises often made about headless CMS, such as separation of concerns and ease of content migration, revealing that these claims often don't align with the reality faced by developers and clients. James is considering integrating Payload directly with Next.js to overcome these limitations and offer a better developer experience, including out-of-the-box features and simpler deployments. Should Payload move to Next.js?

Hey HN, Dan here from Payload (YC S22), an open-source headless CMS that closes the gap between CMS and traditional app frameworks. We’re excited to announce Payload 2.0!

https://github.com/payloadcms/payload

If you’ve not heard of Payload you’re probably wondering why the world needs another CMS. Payload connects to your database and runs without the vendor lock-in and black box of SaaS based CMS solutions, and it’s far more extensible than off-the-shelf SaaS options. Enterprises in specific have been finding value in this control, and they’re using Payload to power content infrastructure that simply isn’t possible through integrating with SaaS webhooks alone.

Today’s announcement is all about features that strike at two neglected areas in the world of CMS. The first is application framework level control over your database that you’d expect with tools like Ruby on Rails or Laravel and the second area is making content editors effective by seeing their edits in realtime.

Here are the highlights on what we’ve been working on:

*Postgres Support*—in the same week we launched about two years ago,people asked for Postgres support. It brings me pure cathartic joy to finally give this to our community. To be fair, MongoDB has been a perfect solution for our architecture and it’s still recommended. But with a new adapter pattern for databases, you can stand your Payload project up on Postgres and run the same functionality as you can with MongoDB now. The crazy part is that we didn’t compromise on how nesting complex fields works. We could have taken the “easy” road and wrote things to JSON, but we leaned fully into the relational way and built the right tables and native column types for fields all the way throughout.

*Database Migrations*—maintaining a production app while deploying schema changes is something you come to expect from ORMs and backend frameworks, but rarely CMS. Payload 2.0 delivers full, first-party migration support all in TypeScript. We took a lot of care on the developer experience here so that when working with Postgres, thanks to our friends at Drizzle, we generate the migration files in TS that add the tables and fields for you. If you have to manipulate data before or after, you have a clear way forward now.

*Database Transactions*—when a request involves multiple inserts, updates or deletes to the database, you need control to rollback all changes when one part fails. The built-in Payload CRUD operations do this now for you and your custom hooks and other code can too.

*Live Preview*—the ability to quickly draft content and see it in context of a website is a literal game changer. We have taken the best dev experience of any headless CMS and given the editors a reason to demand Payload over the others.

*Lexical Richtext Editor*—our original Slate based editor has seen some great features added, like storing related documents directly in the JSON, uploads and any customizations. Unfortunately Slate leaves a lot to be desired on how to extend it, especially compared to Lexical. In a few short weeks we’ve built up a new editor experience inspired by Medium and Notion. Now type “/” and have embedded relationships, uploads, and custom blocks popping right up to be dropped in. Then drag and drop them to reorder your content. If you still want Slate, we continue to support that too.

We’re not compromising on editor experience. This is how we’re bringing the “head” to the headless CMS.

Building critical applications on top of a CMS may sound like blasphemy but it doesn’t have to be that way.

Thanks for reading! I look forward to hearing what you think.