how to debug appwrite function locally?

[small thorn]

Can someone help how to debug appwrite function locally? I cannot fond on the documentation

Thank you

[oak fjord]

You want to execute as a Function without deploying to Appwrite?

[small thorn]

Yes correct,

I want to test it from postman

Without deploy to server

And debug locally

[oak fjord]

Honestly, I usually just push my Function to Appwrite and run, then fix and push again, etc. Pushing Functions to Appwrite is so simple and fast that I don’t really see the point in attempting to run outside Appwrite, where you won’t be in exactly the same environment you’ll be in in production.

If you do really want to run the Functions locally, I can explain how to - what runtime?

[potent hawk]

I think you are not able to test it via postman without deploying at least not that easy, yet you can basically remove context from your function and run it like normal script and add your own debug logs instead of context logs.

[oak fjord]

It is possible, just probably unnecessarily complicated

[quaint merlin]

@small thorn It's pretty easy, you can run any runtime server and export your functionality.

Then you can test your function through postman.

[oak fjord]

Sorry, could you please explain what you mean by this?

[quaint merlin]

It's the middle of the night right now, tomorrow morning I'll do an approximate project and show you.

[oak fjord]

Just wondering what you mean by “run a runtime server”

[oak fjord]

And “export your functionality”

[quaint merlin]

@oak fjord @small thorn @potent hawk
it may be useful to you
https://github.com/ekamalov/bun-debug.git

you can debug your code, use breakpoints.

open via vscode, run code

don't forget to add header
x-open-runtimes-secret

this fully meets the requirements of the runtime

but I'm seeing some problems with the BUN, you can use other runtimes.

we discuss the problem here https://discord.com/channels/564160730845151244/1191788381999468685

breakpoint

[oak fjord]

I don’t see where you’re exposing a web server here?

[quaint merlin]

sorry check now, i added server

https://github.com/ekamalov/bun-debug.git

[oak fjord]

You got that from here, right?

But while this would be ok for basic debugging, you’re still not in the same environment you’ll be in when you ultimately deploy to Appwrite. If you’re going to do this locally, I’d say it would be better to spin up the correct open-runtimes container, and build exactly like Appwrite would.

[quaint merlin]

@oak fjord

There is no special difference, the server.ts file is taken from the original runtime package from appwrite. Debug is very poor locally, you can install breakpoints and see what happens there. This reduces the development time for me by at least 30%.

[oak fjord]

I’m aware that you’ve used the server.ts from the OpenRuntimes Bun runtime, and 99% of the time, that’ll be fine. However, there can absolutely be issues you’ll run into because you’re not actually in the same environment.

[signal thorn]

The problem with Appwrite not providing an official way of how to develop and test code locally in my opinion, is simple.

When you are still prototyping a function or whatever functionally, breakpoints, console.logs and other utilities are extremely import to get:

1. Good coverage on the functionality
2. Test it really good before deploying
3. Fast feed back loops.

Personally, yesterday, I had this issue. Took me 3 hours to fix simple functionality? Why? I had to:

A) Deploy my serverless function from repository Foo
B) See it fail, take a wild guess where it was failing based on errors without breakpoints
C) Go to an opensource package Bar that I am developing, change source code there
D) Publish to NPM, insert token every other 5m
E) Go back to Foo, install latest, deploy to Appwrite
F) Repeat.

This process would be trivial if I could just spin a local project with Docker. I know this is possible, but information on the web is sparse and most medium posts don't give "professional official advice" or are paid.

Appwrite REALLY needs to add some documentation on how quickly setup a local environment, ideally with an option to replicate your remote production projects. Otherwise, it's difficult to justify adopting Appwrite on anything outside hobby projects.

Don't get me wrong, I really love Appwrite and I am investing a lot into it. Including migrating old projects. But sometimes I feel like I am fighting the wheel.

[oak fjord]

When you say “a local project”, are you referring to a local version of Appwrite? Or just spinning up your Function?

[signal thorn]

A local project.

E.g.: Given this project in Production in the Cloud, create an exact copy (without data), but with the same DB, Collections, Functions, etc. that can be executed locally via Docker. Possibly allowing an additional script to be executed after this command completes, allowing us to mock some data. Thinking PostgreSQL and NGinx configuration files that are read automatically when present by their respective official docker images.

This must be possible, especially since Appwrite did not start on the cloud. Certainly, someone already knows how to do this. Appwrite probably knows how to do it. The problem is there is no dedicated page or official recommended way. More importantly there is no step-by-step guide to get you started. You have to trust random things on the internet that might not work or might not scale down the road.

The closest thing I can think of as a real example, comes from Supabase https://supabase.com/docs/guides/cli/local-development;

Requirements will differ from project to project. That's normal. However, having a getting started, general recommended way is enough to:

a) cover most people's use case;
b) give confidence when doing tiny adaptations, when slightly tweaks are needed to fit a use case;
c) give inspiration on how to do things from scratch, if something very different is needed.

Appwrite is a great platform, but having great features alone only takes us so far. Developers and small teams will move much faster if they are confident that the strategies they are adopting work well to some extend.

Along dev rels could write about is: How to move your latest local changes to a QA environment, and then eventually in to Production. Using the "pipeline" above. Like you would do if you were managing your own services/infra.

A standard way of doing things on Appwrite goes a long way for mass adoption.

[signal thorn]

☝️ forgot to tag you on the reply.

[oak fjord]

Here's the documention on self hosting Appwrite. And here's the docs on migrating a Project from Cloud to that new self hosted instance, and back.

[signal thorn]

Good morning @oak fjord, this addresses my issue more or less, but not completly and that's what I am trying to get at. For instance, I can now see that we can create a "self-hosted" local instance, and then use the migrate from cloud pointing at our local instance to create a local on demand environment for testing. An integrated page/guide on how to do this step by step would be beneficial. Alas, the first part of the problem is addressed.

However, the second part is not, right? I don not want to migrate from self-hosted to a new project, I want to add incremental changes to an existing one. The flow would be:

• Log in the morning.
• Clone/Reuse local development project.
• Open PR gets reviewed by peers.
• Pushes changes to Staging project, without recreating the entire project.
• Tests again, maybe ask QA to test features if complex enough that it's justified.
• Pushes changes to Production project, without recreating the entire project.

How can this be achieved with the documents you linked? I don't think it's possible, we are assuming that it's okay to create a new project, migrate all data to it, which might take some time, then reconfigure all dependencies to point at the new project. Most of the times this is not feasible.

[oak fjord]

That is correct - the dev/staging/production transitions are currently very lacking in Appwrite. There isn’t really any good way to handle that.

However, I don’t think the same really applies to Functions (which this post is about). Appwrite has good support for moving Function versions around, with both the appwrite deploy CLI and GitHub integration (other Git providers are coming).

[signal thorn]

I'm making all these questions on appwrite channel because lately I have been working on this package https://www.npmjs.com/package/@franciscokloganb/appwrite-database-migration-tool;
The intent was to help me apply DB migrations across environments on a personal project; So this answer is not at all related with the topic of this support ticket, but ye...
The package is not complete and it still gets some dls a week, avg of 300, peaked at 600. 🥲 So I assume there is "market" even considering nothing works yet; Ah ah. First need to figure out two things, how to rollback failed transactions. But that is a question for another time, when the UP scripts work.

[oak fjord]

You might want to post this in #🎪│showcase ?

[signal thorn]

When it's fixed trademark

Still gotta figure out a bug on the most important entry point :p

[oak fjord]

We've taken this thread pretty far off track at this point. @small thorn did you get any kind of useful answer here?

[oak fjord]

I'm sure if you posted about it others would be interested in helping out