Wasp•2mo ago

Non-Dev question about APIs

I'm developing an app which will receive calls and return things to an extension. I have all the UI of my app and all the corresponding operations and queries to make it work as I want. In the extension I only have the UI and I want to implement APIs to complete its functionality. In this case I have managed to create an API even with auth with JWT and testing it, the extension has worked. My doubt arises at the moment of creating the API(s). I don't know if it would be the right thing to do, but I can compare the API with an Operation, just that it is carried out externally. Based on this, I don't know if I should create only one API and that API runs ALL the necessary code (there are many operations) or an API for each operation (each operation is simple). Any recommendations? Best practices?

8 Replies

kapa.ai•2mo ago

Hi @NEROX. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- You're asking a great question about API design in Wasp for your extension integration. Let me help you understand the best approach. API Design Options in Wasp In Wasp, you have two main options for exposing functionality to external clients like your extension: 1. Create a single API endpoint that handles multiple operations internally 2. Create multiple API endpoints that each correspond to a specific operation Both approaches are valid, but there are some considerations to help you decide. Best Practices Option 1: Single API Endpoint If you create one API that handles all operations, you would need to implement routing logic inside your API handler to determine which operation to execute based on the request parameters.

export const apiFunction = async (req, res, context) => {
  const { operationType, ...operationParams } = req.body;
  
  // Route to the appropriate business logic based on operationType
  switch(operationType) {
    case 'operation1':
      // Call business logic for operation1
      break;
    case 'operation2':
      // Call business logic for operation2
      break;
    // etc.
  }
};

export const apiFunction = async (req, res, context) => {
  const { operationType, ...operationParams } = req.body;
  
  // Route to the appropriate business logic based on operationType
  switch(operationType) {
    case 'operation1':
      // Call business logic for operation1
      break;
    case 'operation2':
      // Call business logic for operation2
      break;
    // etc.
  }
};

Option 2: Multiple API Endpoints Creating separate API endpoints that mirror your operations is generally considered a better practice because: 1. It follows RESTful principles better 2. Each endpoint has a clear, single responsibility 3. It's easier to maintain and debug 4. You can reuse your existing business logic You can implement this by creating multiple API declarations in your Wasp file and reusing your operation logic:

// In your actions.js/ts file
export const businessLogic = async (params, context) => {
  // Your operation logic here
}
// Can be used both in your operation and API
export const myOperation = async (args, context) => {
  return businessLogic(args, context);
}

// In your actions.js/ts file
export const businessLogic = async (params, context) => {
  // Your operation logic here
}
// Can be used both in your operation and API
export const myOperation = async (args, context) => {
  return businessLogic(args, context);
}

Then in your Wasp file:

api myApiEndpoint {
  fn: import { myOperation } from "@src/server/actions.js",
  entities: [User],
  httpRoute: (POST, "/my-endpoint"),
  auth: true
}

action myOperation {
  fn: import { myOperation } from "@src/server/actions.js",
  entities: [User]
}

api myApiEndpoint {
  fn: import { myOperation } from "@src/server/actions.js",
  entities: [User],
  httpRoute: (POST, "/my-endpoint"),
  auth: true
}

action myOperation {
  fn: import { myOperation } from "@src/server/actions.js",
  entities: [User]
}

This approach is demonstrated in the Discord conversation where a community member shows how to share business logic between APIs and Operations Discord support thread. Recommendation For your extension case, I recommend creating separate API endpoints for each distinct operation. This will: 1. Make your API more maintainable 2. Allow you to reuse your existing operation logic 3. Provide clearer error handling 4. Make it easier to add authentication to specific endpoints The Wasp team is also working on automatically exposing APIs based on defined Operations, which would make this even easier in the future, as mentioned in this GitHub issue. Remember that APIs in Wasp are designed specifically for these external integration cases, while Operations are meant for the internal client-server communication within your Wasp app. GitHub: Kapa AI ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @NEROX, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

NEROXOP•2mo ago

@kapa.ai Wait, can I call an operation within an API? Without the need to rewrite the logic I would do?

kapa.ai•2mo ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- Yes, you can call an operation directly within an API implementation in Wasp without rewriting your logic. This is a great approach for code reuse. When implementing an API, you can import and call the same business logic function that your operation uses. Here's how you can structure it: 1. Create a shared business logic function that both your operation and API can use 2. Import that function in both your operation and API implementations Here's an example of how this would look:

// src/server/actions.js
// Shared business logic function
export const businessLogic = async (args, context) => {
  // Your core logic here
  // ...
  return result;
}

// Operation implementation that uses the business logic
export const myOperation = async (args, context) => {
  return businessLogic(args, context);
}

// API implementation that uses the same business logic
export const myApiHandler = async (req, res, context) => {
  const args = req.body; // Extract arguments from request
  const result = await businessLogic(args, context);
  return result;
}

// src/server/actions.js
// Shared business logic function
export const businessLogic = async (args, context) => {
  // Your core logic here
  // ...
  return result;
}

// Operation implementation that uses the business logic
export const myOperation = async (args, context) => {
  return businessLogic(args, context);
}

// API implementation that uses the same business logic
export const myApiHandler = async (req, res, context) => {
  const args = req.body; // Extract arguments from request
  const result = await businessLogic(args, context);
  return result;
}

Then in your Wasp file:

action myOperation {
  fn: import { myOperation } from "@src/server/actions.js",
  entities: [User]
}

api myApiEndpoint {
  fn: import { myApiHandler } from "@src/server/actions.js",
  entities: [User],
  httpRoute: (POST, "/my-endpoint")
}

action myOperation {
  fn: import { myOperation } from "@src/server/actions.js",
  entities: [User]
}

api myApiEndpoint {
  fn: import { myApiHandler } from "@src/server/actions.js",
  entities: [User],
  httpRoute: (POST, "/my-endpoint")
}

This pattern is shown in the Discord support thread where a community member demonstrates exactly this approach:

api generateTextToTextResponse {
  fn: import { generateTextToTextResponse } from "@src/server/actions.js",
  entities: [User],
  httpRoute: (POST, "/generate-text-to-text-response")
}

action generateTextToTextResponse {
  fn: import { generateTextToTextResponse } from "@src/server/actions.js",
  entities: [User]
}

api generateTextToTextResponse {
  fn: import { generateTextToTextResponse } from "@src/server/actions.js",
  entities: [User],
  httpRoute: (POST, "/generate-text-to-text-response")
}

action generateTextToTextResponse {
  fn: import { generateTextToTextResponse } from "@src/server/actions.js",
  entities: [User]
}

Discord support thread This approach keeps your code DRY (Don't Repeat Yourself) and ensures consistency between your internal operations and external API endpoints. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @NEROX, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

Vinny (@Wasp)•2mo ago

Is the bot answering your questions @NEROX ?

NEROXOP•2mo ago

@kapa.ai How secure is wasp:sessionId to use as auth in a Chrome extension that calls the app API?

kapa.ai•2mo ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- Based on the knowledge sources, I can provide some insights about using Wasp's session authentication in a Chrome extension context. Wasp's Session Authentication Wasp has moved from JWT-based authentication to session-based authentication using the Lucia Auth v3 library. According to the documentation:

Wasp's auth uses sessions to keep track of the logged-in user. The session is stored in localStorage on the client and in the database on the server. Under the hood, Wasp uses the excellent Lucia Auth v3 library for session management.

When users log in, Wasp creates a session for them and stores it in the database. The session is then sent to the client and stored in localStorage. When users log out, Wasp deletes the session from the database and from localStorage. Security Considerations for Chrome Extensions For Chrome extensions connecting to a Wasp backend, there are several security considerations: 1. Storage mechanism: Wasp currently stores session IDs in localStorage, which is accessible via JavaScript. This makes it potentially vulnerable to XSS attacks compared to HttpOnly cookies. 2. Token invalidation: With session-based auth, the server can invalidate sessions when needed (like during logout), which is more secure than stateless JWTs that remain valid until they expire. 3. Cross-domain concerns: If your extension is making cross-domain requests to your Wasp backend, you'll need to ensure proper CORS configuration. Recommendations for Chrome Extension Auth Based on a similar discussion in the Discord thread about Chrome extension authentication: 1. Using JWT tokens for extension authentication was recommended: "use custom API endpoints and have a way to create JWT tokens... Store the JWT tokens in local storage." 2. For your specific case with wasp:sessionId, since Wasp is already using session-based authentication, you could leverage this existing mechanism, but be aware that: - The session is stored in localStorage which is accessible to JavaScript - There have been discussions in the Wasp community about moving to cookies instead of localStorage for better security If you're building a Chrome extension that needs to authenticate with your Wasp backend, you might want to consider: 1. Creating a dedicated API endpoint for extension authentication 2. Using HTTPS for all communication between your extension and backend 3. Implementing proper token validation on the server side 4. Being cautious about how you store authentication tokens in your extension The Wasp team has been discussing improvements to their authentication system, including potentially moving from localStorage to cookies for better security, but this hasn't been fully implemented yet according to the knowledge sources. Would you like more specific information about any particular aspect of implementing authentication between your Chrome extension and Wasp backend? ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @NEROX, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

NEROXOP•2mo ago

@kapa.ai What would be the difference in the Extension and the Api using wasp:sessionId or for getSessionId() from wasp/client/api? Is the same? Explain the differences, could I get sessionId from API call?

kapa.ai•2mo ago

Let me check the knowledge base for you again. One moment! :books: ---------------------- Based on the knowledge sources provided, I don't have specific information about wasp:sessionId or getSessionId() from wasp/client/api in the context of Chrome extensions. The knowledge sources don't explicitly mention these specific functions or how they would be used in an extension context. What I can tell you from the available information is: 1. Wasp uses session-based authentication with Lucia Auth v3, storing sessions in localStorage on the client and in the database on the server. 2. For Chrome extensions, one approach mentioned in the Discord thread is to "generate a JWT key when the user logs in" and use that for authentication between the extension and your Wasp backend. 3. There are discussions in the Wasp community about moving from localStorage to cookies for better security, but this hasn't been fully implemented yet. Regarding your specific question about getting a sessionId from an API call - the knowledge sources don't provide explicit information about this. However, based on how authentication typically works, you would usually: 1. Authenticate through a dedicated endpoint (like login) 2. Receive authentication credentials (session ID, token, etc.) 3. Use those credentials in subsequent API calls If you need specific information about wasp:sessionId or getSessionId(), I'd recommend: 1. Checking the Wasp documentation for these specific functions 2. Asking in the Wasp Discord community for more specific guidance on extension authentication 3. Looking at the Wasp source code to understand how these functions are implemented Would you like me to provide more general information about authentication approaches between Chrome extensions and web backends? ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @NEROX, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

Gaming

Programming

Non-Dev question about APIs

Did you find this page helpful?