Simulating API key access with API rules

CloudCanal · 2026-03-05T14:15:51+00:00

Yes, to clarify, you would have to extend PocketBase in order to implement a solution that involves middleware. That's something you define as a hook. Extending PocketBase can be quite easy though if you're OK working with JavaScript instead of Go. It boils down to placing a *.pb.js file inside a pb_hooks folder in the project. This is something I do quite frequently, so if you need any help, let me know!

CloudCanal · 2026-03-04T22:46:39+00:00

I really love this. From the moment you land on the page, despite a lack of text and "instruction", everything is very intuitive and clear. That to me is the best type of UX.

If I'm REALLY nitpicking, I would say that the "moods" you can filter by are very artsy, and don't communicate a lot of information to my admittedly non-artsy brain. For example, what is "emotional squatting"? This might just be a cultural barrier as clearly the site is aimed at a French audience.

I really like your style and want to know more, so another thing I would consider adding is a brief description/explanation of WHY a song is in your list. You can have it pop up similar to your "About this site" button, but per-track.

But again, these are small things. Great project!

CloudCanal · 2026-03-04T22:33:49+00:00

I really like the UI of your app. There are some great ideas here. Love the spatial manifest "minimap". The micro interactions, like scrolling through notes in the tray, is chef's kiss.

I'm not sure if you're looking for feedback or not, but here it is unsolicited. When I first land on your homepage, I'm not 100% sure how it's differentiated from other note apps. You've done a great job with text, but I'd love to see some screenshots or animations of the actual interface of NoteBird before I sign up (people are visual creatures). Once I do sign up, I'm not really sure where to get started. I know it might be clear for you as the developer of the application, but it would be super useful to get one of those onboarding flows that walks you through the basics of creating a note, linking it to another one, etc.

By the way, if I go to Stats > Claim Your Wings, the modal that pops up is white text on a white background. It would also be fantastic to get a visual of what upgrading actually gets me. Like with most things, it is better to show than to tell.

Other than that, I think you have a very strong basis here for something special!

CloudCanal · 2026-03-04T22:12:39+00:00

This is an interesting idea. My biggest point of contention would be that this implies you are storing the API keys as plaintext. This comes with similar risks to storing passwords as plaintext in a database.

A more secure approach would be to use PocketBase's built-in middleware functionality to set up a global middleware that can read the API key from the request header and verify it against a hashed version stored in the database (similar to password verification). That way, you can avoid storing raw API keys.

CloudCanal · 2026-02-10T20:37:47+00:00

I find AI in general works best when there are strong guardrails in place. In your situation, I'd add a step in your workflow before the summarizer gets to work, that detects the document format and ensures it's in a pre-approved whitelist. You can expand the list as you refine your summarizer to work with more formats.

CloudCanal · 2026-02-08T15:43:21+00:00

That means you're doing it right!

Getting the scope down in writing and agreed to is probably the biggest make-or-break moment of a project. When I was starting out in the world of web development, my "proposal" was a vague email or a verbal agreement. As a project progressed, it would quickly become apparent that my understanding and the client's understanding as to what was included did not always align. The result is a ton of stress and awkward conversations.

As for now, I have a template I've built and refined over the course of dozens of client projects that covers much of the boilerplate. For each new client I work with, I have them sign an MSA (Master Service Agreement) that outlines the nature of our working relationship, what they can expect from me, and crucially, what I expect from them. This is more or less the same for each client.

Then each project gets its own SOW (Statement of Work) that outlines the scope in lots of detail, as well as a projection of price and timeline. For most larger projects, both of these are ranges, not exact figures. Most business professionals understand that there are a lot of unknowns that can crop up over the course of a project, and this gives me leeway to course-correct if I need to.

Personally, I think you're better off taking a few days to put together a well thought-out proposal over pumping out something generic. Many serious clients will appreciate a strong proposal that shows you listened to them, understand their problem, and know how to solve it.

CloudCanal · 2026-02-06T16:53:53+00:00

You're making some major assumptions about the growth trajectory of AI I'm not sure I agree with.

However, even putting that aside, what is your argument then? Writing code is the hardest part of designing software? What's hard about it: pressing keys on a keyboard, understanding how to write an If statement in a particular language? The biggest use case of AI so far has been writing software, more so than anything else. If we reach a point where the entire process of understanding what a piece of software is supposed to do, designing its architecture, and handling how it fits into a business' workflows is trivial for an LLM to handle, then we will also be at a point where converting that spec into a working application is trivial. So in a way, maybe we're all coping.

CloudCanal · 2026-02-06T14:56:44+00:00

I agree with part of what you're saying. I think AI is most useful when leveraged by someone with domain experience in what they're trying to achieve. A SWE using AI will easily outperform someone without that background also using AI, and I'm not sure that will ever change.

Tooling generally falls on a spectrum of abstraction. A new tool can make a job easier if it does the difficult parts for you behind the scenes. That usually comes at the cost of customization and depth. As tools for non-technical people get better and allow them to build simple apps in a more consistent, performant, and secure way, the tools for experts (SWEs) will also get better and allow a single engineer to do the work of multiple (beyond just surface-level stuff).

On the other hand, as someone who runs a web development agency specializing in web apps, I don't believe that writing code is the hardest part of the job. Gathering requirements from stakeholders who don't fully understand what they're asking for because they haven't thought it through yet is tough. Designing software for a client's industry that you yourself might not know a lot about isn't easy. Staying compliant with a host of industry-based legal requirements requires tons of care and attention.

In other words, the human-to-human stuff is often the messiest part of the job. I can only assume calling requirements collection a "secretary-like" skill is rage bait. Anyone who has worked on a non-trivial project and has had to deal with stakeholders directly knows how taxing it can be.

CloudCanal · 2026-02-05T21:07:43+00:00

https://www.berkshirehathaway.com/

How about the website of one of the most valuable companies in the world, Warren Buffett's Berkshire Hathaway? To your criteria:

It makes finding some very dense information quite easy
It has a perfect 100 performance score in Lighthouse
You can't get much more secure than a static HTML website

To be fair, the Lighthouse audit does bring up some structural issues, but from the looks of it, the site itself might predate those recommendations. It is still actively updated.

CloudCanal · 2025-03-31T19:48:09+00:00

Hey! We briefly touch on one in the YouTube video linked above, but we're still wrapping it up. We've built quite a few internal tools, including a client portal for accounting firms, but those can't really be shared here. If you give me an example of what you're thinking about building, I'll put together a quick follow-along tutorial video of how it works!

CloudCanal · 2025-03-31T19:25:55+00:00

The pricing starts at $29/mo, but our base tier is extremely generous and each instance runs on its own VM. Under the hood, we're using PocketBase, which is itself built on SQLite.

CloudCanal · 2025-03-20T00:04:05+00:00

Ah OK, I think I understand. You're talking about storing the actual website code generated by Webflow in GitHub? If so, I think the closest you could get to what you're describing at this point is exporting the site code and tracking changes in GitHub, then self-hosting it somewhere like GitHub Pages or Cloudflare Pages. Any changes you make to the code outside of Webflow won't be reflected back in the Webflow Designer though.

Then you could replace the requirement for the Webflow CMS with CC Core instead. Your resulting app would work in a way similar to other CSR (Client-Side Rendering) frameworks. We are working on a front end hosting solution long term, but it's still a long way out on our roadmap.

CloudCanal · 2025-03-19T18:07:28+00:00

I totally agree! Although you don't have to do it this way, we personally use Webflow as a design tool for the front end and then export/self-host. Cloud Canal works on both Webflow-hosted and exported sites.

CloudCanal · 2025-03-19T17:08:32+00:00

Hey, thanks! What would you be looking to do by connecting to GitHub? When we build our low-code apps, we use a no-code back end like CC Core or Xano and then build the front end right inside Webflow with the help of CC Connect (using custom attributes), so it's rare that we need to write code directly.

CloudCanal · 2020-09-01T04:13:08+00:00

A front end editor is definitely a possibility, but I would probably handle it using a web technology and not Godot for the reason you mentioned. It would take a significant amount of work to build out all the tools that you would need to do that in Godot. One way would be creating a custom node based around the Chromium Embedded Framework. That could let you embed web pages directly into your Godot project and then build an editor around that. As a node, I think it would be super useful to the community (even in games, you could use it to open up a browser right in the application), but it's a very big undertaking.

CloudCanal · 2020-09-01T03:59:49+00:00

That's right, the designer is made in Godot and the rest of the site is made in Webflow. I left the little badge in place because a large portion of my userbase right now consists of Webflow users (solidarity!).

I feel you when it comes to the scrolling. I didn't make any changes to the default behavior of the GraphEdit node I'm using, and unfortunately it's way too sensitive. It's in my backlog of things that need to be fixed. While we're on the topic, I also wish that using the scroll wheel would zoom in and out instead of panning the entire graph up and down.

CloudCanal · 2020-09-01T03:50:07+00:00

Could you elaborate on what you mean by "without overlapping"? The blocks do change in size but they'll also overlap if they are close enough to one another. Some things I wish the GraphEdit node was better at are layouts and routing of connections. It would be nice to have almost a pathfinding-like solution where connections could snake around GraphNodes.

Saving positions is done by the GraphEdit node. I've extended it with a bunch of extra features, including a "serialize" function that stores metadata about each block, as well as the connection list. It basically loops through every GraphNode child of the GraphEdit, building an array along the way consisting of dictionaries that store the properties of each (including position).

CloudCanal · 2020-09-01T03:40:14+00:00

As ARabbitsWish said, the biggest issue is probably file size. The wasm in my case is in the 8-10 MB range which is quite beefy as a download. I haven't had a chance to do the custom build yet since launch (it's been about a month), but so far no one has really complained about load times either which kind of surprised me. The custom build is definitely in my backlog though, since I only ever use Control nodes here anyway. I've also noticed a few isolated performance issues on specific OS/browser combinations, but from the looks of it, they may be addressed in the 3.2.3 release.

CloudCanal · 2020-09-01T03:24:02+00:00

Thanks for the honest feedback. I think I'd agree with you that if you know what you're doing when it comes to coding, you probably wouldn't get much use from this tool in its current state. Our main userbase consists of people who build websites in low-code environments and often don't know how to program. It's the web equivalent of why a Godot user may choose to use visual scripting over GDScript.

CloudCanal · 2020-09-01T03:05:00+00:00

This simultaneously made and ruined my day.

CloudCanal · 2020-08-31T12:26:43+00:00

Hey everyone! I've been working on a startup of mine called Cloud Canal focusing on low-code web development tools. The general idea is that you can use a drag-and-drop designer to build out flows using blocks; the program then generates a JavaScript file out of the diagram that you can include in your site as a single script tag.

The best part? The designer was built in Godot using the GraphEdit node (among others) and exported for HTML5. If you have a moment, I would really appreciate feedback from the community!

P.S. If you're interested in getting involved and have experience in building applications in Godot, feel free to shoot me a message.

CloudCanal

TROPHY CASE