MCP, Asynchronus vs. Synchronus#3105
Open
aishwaripahwa12 wants to merge 9 commits into
Open
Conversation
Appwrite WebsiteProject ID: Website (appwrite/website)Project ID: Tip Schedule functions to run as often as every minute with cron expressions |
Contributor
Greptile SummaryThis PR adds two new SEO-focused blog posts — one on asynchronous vs. synchronous programming and one on Model Context Protocol — along with their cover images and corresponding
Confidence Score: 5/5Two new blog posts and their assets — no application logic changed, no migrations, no auth paths touched. The changes are purely additive content (Markdoc files and AVIF images). The SDK code examples are correct, FAQs are distinct, internal links point to valid paths, and the cache entries are consistent with project conventions. No files require special attention. Important Files Changed
Reviews (4): Last reviewed commit: "Delete static/images/blog/what-is-crud-e..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
aishwaripahwa12
commented
Jul 16, 2026
aishwaripahwa12
commented
Jul 16, 2026
aishwaripahwa12
commented
Jul 16, 2026
aishwaripahwa12
commented
Jul 16, 2026
aishwaripahwa12
commented
Jul 16, 2026
aishwaripahwa12
changed the title
adityaoberai
requested changes
Jul 22, 2026
| - question: When should I use synchronous programming? | ||
| answer: Use synchronous programming for quick calculations, startup tasks, simple scripts, and operations that must run in a strict order. It is often easier to read, test, and debug. | ||
| --- | ||
| Most performance problems in application code come down to one decision made early and rarely revisited: whether a piece of work runs synchronously or asynchronously. Get it wrong and a single slow network call freezes your entire request, your UI stops responding, and your server sits idle waiting on I/O it could have handled in parallel. |
Contributor
There was a problem hiding this comment.
Suggested change
| Most performance problems in application code come down to one decision made early and rarely revisited: whether a piece of work runs synchronously or asynchronously. Get it wrong and a single slow network call freezes your entire request, your UI stops responding, and your server sits idle waiting on I/O it could have handled in parallel. | |
| Most performance problems in application code come down to one decision made early and rarely revisited: whether a piece of work runs synchronously or asynchronously. Get it wrong and a single slow network call freezes your entire request, your UI stops responding, and your server sits idle waiting on I/O it could have handled in parallel. |
Comment on lines
+128
to
+147
| # Handling synchronous and asynchronous work with Appwrite | ||
|
|
||
| Once you move this decision from a single function into a real backend, you need infrastructure that supports both models cleanly. [Appwrite Functions](/docs/products/functions) is built around exactly this distinction. | ||
|
|
||
| When you [execute a function](/docs/products/functions/execute), you choose the mode explicitly. A **synchronous execution** makes the caller wait for the result and is capped at a 30-second timeout, which suits API endpoints and short tasks where you need the response immediately. An **asynchronous execution** returns an execution ID right away and runs the work in the background, which suits long-running jobs like batch processing, email delivery, or upload post-processing. | ||
|
|
||
| ```javascript | ||
| const execution = await functions.createExecution({ | ||
| functionId: '<FUNCTION_ID>', | ||
| async: true, // returns immediately, runs in the background | ||
| }); | ||
| ``` | ||
|
|
||
| Beyond Functions, the same non-blocking philosophy runs through the platform. [Appwrite Realtime](/docs/apis/realtime) pushes updates to clients over subscriptions instead of forcing them to poll, and [Appwrite Messaging](/docs/products/messaging) handles email, SMS, and push delivery as background work so your request path stays fast. Together they let you keep user-facing calls synchronous and responsive while heavy work happens asynchronously out of the critical path. | ||
|
|
||
| To go deeper on structuring this well, read the [complete guide to Appwrite Functions](/blog/post/appwrite-functions-guide) for triggers and execution modes, and [serverless functions best practices](/blog/post/serverless-functions-best-practices) for patterns that keep async work reliable in production. | ||
|
|
||
| # Getting started with Appwrite Functions | ||
|
|
||
| Choosing between synchronous and asynchronous execution is not about picking a favorite. It is about matching the model to the work: synchronous for fast, CPU-bound, order-dependent tasks, and asynchronous for anything that waits on I/O or runs long. Get that mapping right and both your servers and your users stop waiting on work that never needed to block them. |
Contributor
There was a problem hiding this comment.
If we're talking about Appwrite, we should talk about DevEx and our SDKs. This doesn't exactly make sense right now. Our SDKs use async functions, so we can mention that,
We can then make a Functions-specific section if we want, but the whole article doesn't really allude to how we have it framed right now so it feels off.
| - question: Is MCP secure? | ||
| answer: MCP can support authorization for remote HTTP servers, but connecting a server still gives an AI application access to potentially sensitive tools and data. Developers should use narrowly scoped credentials, validate inputs, require approval for sensitive actions, and only connect trusted servers. | ||
| --- | ||
| AI models are good at reasoning and terrible at acting. Ask one to summarize your latest report, check today's database entries, or open a pull request, and it stalls. It has no way to reach your files, your database, or your APIs. It can only work with what was in its training data. |
Contributor
There was a problem hiding this comment.
Suggested change
| AI models are good at reasoning and terrible at acting. Ask one to summarize your latest report, check today's database entries, or open a pull request, and it stalls. It has no way to reach your files, your database, or your APIs. It can only work with what was in its training data. | |
| AI models are good at reasoning and terrible at acting. Ask one to summarize your latest report, check today's database entries, or open a pull request, and it stalls. It has no way to reach your files, your database, or your APIs. It can only work with what was in its training data. |
|
|
||
| MCP is an open protocol that defines how AI applications connect to external tools, data sources, and APIs through a uniform interface. Instead of teaching a model a new integration for every service, you expose your capabilities through an **MCP server**, and any MCP-compatible client can use them. | ||
|
|
||
| MCP was developed by [Anthropic](https://www.anthropic.com/news/model-context-protocol) and released as an open standard in November 2024. It has since been adopted across IDE assistants, desktop clients, and backend platforms, and the specification is maintained openly at [modelcontextprotocol.io](https://modelcontextprotocol.io). |
Contributor
There was a problem hiding this comment.
While Anthropic started MCP, it is now maintained by the Agentic AI Foundation (https://aaif.io/)
Comment on lines
+96
to
+105
| # How to start building with MCP | ||
|
|
||
| You do not need to implement the protocol by hand. The MCP project ships official [SDKs](https://modelcontextprotocol.io/docs/sdk) for TypeScript, Python, and other languages that handle the JSON-RPC layer, the handshake, and the transport for you. Building a server usually comes down to declaring your tools, resources, and prompts and wiring them to real logic. | ||
|
|
||
| If you are using MCP rather than authoring a server, the workflow is simpler: pick a client, point it at a server, and start prompting. The client handles discovery and tool calls automatically. | ||
|
|
||
| Two good ways to get hands-on: | ||
|
|
||
| * **Use existing servers.** Attach servers for the tools you already work with. Our roundup of the [best MCP servers and clients](/blog/post/10-best-mcp-server-client) is a good starting point for what is available. | ||
| * **Connect your backend.** If you build on Appwrite, the [Appwrite MCP server](/docs/tooling/ai/mcp-servers/api) exposes your project to any MCP-compatible client so an AI agent can manage [Databases](/docs/products/databases), create users through [Auth](/docs/products/auth), upload files to [Storage](/docs/products/storage), and deploy [Functions](/docs/products/functions) directly from a chat. |
Contributor
There was a problem hiding this comment.
This should instead refer to how to build an MCP server
| * **Use existing servers.** Attach servers for the tools you already work with. Our roundup of the [best MCP servers and clients](/blog/post/10-best-mcp-server-client) is a good starting point for what is available. | ||
| * **Connect your backend.** If you build on Appwrite, the [Appwrite MCP server](/docs/tooling/ai/mcp-servers/api) exposes your project to any MCP-compatible client so an AI agent can manage [Databases](/docs/products/databases), create users through [Auth](/docs/products/auth), upload files to [Storage](/docs/products/storage), and deploy [Functions](/docs/products/functions) directly from a chat. | ||
|
|
||
| # MCP security best practices |
Contributor
There was a problem hiding this comment.
This can be a separate blog
|
|
||
| Scope API keys to the minimum permissions the task needs, prefer local stdio servers when you want credentials to stay on your machine, and use staging projects for exploratory work. Before connecting any server, audit which tools it exposes. An MCP server is only as safe as the access you hand it. | ||
|
|
||
| # Getting started with the Appwrite MCP server |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Latest SEO Blogs