tailcallhq / tailcall Goto Github PK

Description:
When a tailcall server is configured without a resolver at the root level, it starts successfully. However, it doesn't respond to any requests, which can be misleading for developers. This behavior should be addressed by enforcing the presence of a resolver at compile time.

Reproduction Steps:

1. Configure the tailcall server without a root-level resolver.
2. Start the server.
3. Observe that the server starts successfully without errors.
4. Make a request to the server.
5. Notice the server provides no response.

Example Configuration with Issue:

type Query {
  user: [User]! # Unresolved root level configuration
}

type User {
  id: ID
  name: String
  posts: [Post] @http(path: "/posts/{{value.id}}") 
}

Proposed Solution:
If a configuration lacks a resolver at the root level and none can be inferred, a compile-time error should be thrown, clearly indicating the absence of a necessary resolver. This ensures that developers are aware of the missing resolver before runtime.

Update 1
This should only be applicable for scenarios where the type of the field is required. In a scenario where the field is not required, it's totally fine if there are no resolvers.

This happens when you run the tests a couple of times in sequence.

WARNING: An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.
java.lang.OutOfMemoryError: Direct buffer memory
	at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
	at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:118)
	at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:317)
	at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:632)
	at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:607)
	at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:202)
	at io.netty.buffer.PoolArena.tcacheAllocateSmall(PoolArena.java:172)
	at io.netty.buffer.PoolArena.allocate(PoolArena.java:134)
	at io.netty.buffer.PoolArena.allocate(PoolArena.java:126)
	at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:395)
	at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188)
	at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179)
	at io.netty.buffer.AbstractByteBufAllocator.ioBuffer(AbstractByteBufAllocator.java:140)
	at io.netty.channel.DefaultMaxMessagesRecvByteBufAllocator$MaxMessageHandle.allocate(DefaultMaxMessagesRecvByteBufAllocator.java:114)
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:150)
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:829)

Description:
The current compiler does not catch potential issues when a field that can be undefined or optional is used in the route parameter of Http. To enhance robustness and provide clearer developer feedback, the compiler should be improved in the following areas:

1. Potentially Undefined Route Parameter:
   When a field that can be undefined or optional is used in the route parameter of Http, the code should not compile to prevent potential runtime issues.

   Examples:

   type Query {
      user(id: Int): User @http(path: "/user/{{args.id}}")
   }

   In this first example, since id is an optional parameter, using it directly in the route should trigger a compiler error.

   type Post {
      id: ID
      userId: ID
      user: User @http(path: "/users/{{value.userId}}")
   }

   In the second example, the userId field is not guaranteed to always be present in a Post. Using it in the path should also raise a compiler error, as it can lead to unexpected behavior or failures.

2. Undefined References:
   The compiler should be enhanced to detect any values, fields, arguments, etc. that are used but not defined, and raise appropriate errors.

We have recognized a recurring problem concerning the maintenance and susceptibility to errors when manually writing a codec for each modification in our Config structure. The existing process of employing Config2Document and Document2Config transcoders for these changes is resource-intensive.

To rectify this, we propose creating a Universal Codec, which will replace the individual transcoders. This codec will facilitate efficient conversion between Config and Document and vice versa, and crucially, it will handle changes in the Config structure without needing a rewrite.

Our plan is to develop this Universal Codec leveraging the power of ZIO Schema and our existing Directive Codec. Building on ZIO Schema allows us to derive codecs automatically based on the schema of the data. By doing so, we can deprecate the Config2Document and Document2Config transcoders, thereby reducing maintenance overhead, and improving our code's efficiency and reliability.

We will post updates on this issue as we progress with this implementation. Your feedback or suggestions are always welcome. We are looking forward to this significant improvement in handling Config and Document conversions.

requesting the blueprint when not found, results in an error. This is cached and even after publishing doesn't get fixed.

Homebrew is a standard way to install CLI applications for mac users. Ideally we would want to give developers a similar experience.

> brew install tailcall
> tc --help

After a release has been made, we should update a homebrew formula with the latest version automatically.

Create an encoder service that converts an Open API Specification into a list of Encoder.

Requirements

• Use ZLayer based service pattern
• Write unit test
• Create an ADT for Open API copy and attribute from https://github.com/zio/zio-http/blob/main/zio-http/src/main/scala/zio/http/endpoint/openapi/OpenAPI.scala

trait OpenAPIEndpointEncoder {
  def encode(api: OpenAPI): List[Endpoint]
}

object OpenAPIEndpointEncoder {
   final case class Live() extends OpenAPIEndpointEncoder {
     override def encode(api: OpenAPI): List[Endpoint]  = ???
   }
}

Update Tailcall documentation with an example of composing rest endpoints into a graphql schema

Sample Usage

type User {
  id: ID
  name: String
}

type UserQuery @extends(type: "User") {
  posts: [Post] @http(path: "/users/{{value.id}}/posts")
  comments: [Comment] @http(path: "/users/{{value.id}}/comments")
}

type Post {
  id: Int!
  userId: Int!
  title: String!
  body: String!
  user: User @http(path: "/users/{{value.userId}}")
  comments: [Comment] @http(path: "/posts/{{value.id}}/comments")
}

type Query {
  users: [UserQuery] @http(path: "/users")
  posts: [Post] @http(path: "/posts") 
}

In the above example you can request for UserQuery from root Query and perform a deeply nested query. This makes sense at root level, however, if we don't want to provide this capability for other types such as Post, we create a new type called User which has a limited set of fields. This way we restrict the kind of queries that can be made by client and provide stronger compile time performance guarantees specially around N + 1 API calls.

Implementation

• Validations -

  • Types exists in the @extends directive
  • fields are not overridden by the extender.
  • A type can extend only one type at a time.

• Type Generation - Two types are generated with a common set of defined in the base type. An Interface from the base type called IUser is generated which is implemented by User and UserQuery

  interface IUser {
    id: ID
    name: String
  }
  
  type User implements IUser {
    id: ID
    name: String
  }
  
  type UserQuery implements IUser {
    id: ID
    name: String
  
    # .. rest of the UserQuery fields
  }
  
  # rest of the types

• Resolver - Should base type resolvers should be copied to the child resolvers (practically we copy the complete field)

NOTE:

• There could a type hierarchy of multiple levels, eg: UserQuery extends User and User extends Person and Person extends Living. In that case, all intermediate interfaces and types should be generated recursively.

@modify should not be possible on fields that are being implemented via an interface. Compiler should throw an error when modify is used this way.

The draft job builder isn't adding version numbers to the artifact created.

For the user interface be it YML/JSON or a WEB UI, we should be able to use standard JQ syntax for accessing deeply nested values. Currently, mustache uses . to access deeply nested values, but it's not very standard. Using JQ syntax we can make it easier for developers consume the DSL.

Proposal
The proposed way is to extend the mustache parser with support for JQ syntax.

References
https://stedolan.github.io/jq/tutorial/

Currently, the Remote library does not include the Seq class or its corresponding methods. This issue aims to implement Seq and its operators in Remote, including all standard library methods. Additionally, we propose to refactor the Map implementation by dropping redundant operators and implementing it via sequence.

To achieve this, we will need to:

Implement the Seq class in Remote.
Implement all standard library methods of Seq, such as map, filter, flatMap, etc.
Refactor the Map implementation to drop redundant operators such as concat, remove etc.

Tasks:

• Implement Seq class in Remote.
• Add all standard library methods of Seq to Remote (Try using chat GPT to generate the classes)
• Refactor the Map implementation by
  • dropping redundant operators and implementing it via sequence.
  • Implementing Map specific operators as a subtype of Seq operations
• Write unit tests to ensure the functionality of Seq and Map in Remote and Lambda

References
Can find references to operators here — https://docs.scala-lang.org/overviews/collections-2.13/seqs.html#inner-main

Currently, the Remote DSL for Scala lacks several important Map operators, including ++, --, and getOrElseUpdate. These operators are crucial for working with Scala Maps in a concise and expressive way, and their absence in the Remote DSL is limiting the functionality of the library.

I propose that we add these missing operators to the Remote DSL. Specifically, we should add the following methods to the MapOps trait:

These operators should be implemented in a way that is consistent with the existing Map operators in the Remote DSL, and with the Scala standard library.

Feel free to list down and add other standard Scala Map operators.

Identifying blueprints by hash is not developer friendly. There are to main issues with it —

• It's difficult to know just by looking at the hash if it's a new version or an older version.
• It's not obvious if there are new features or breaking changes introduced with the latest version.

The proposal is to use semantic versioning for blueprints. So one could query schemas as - /graphq/0.1.2

• Major: Breaking changes in schema from the latest version - field drop or type drops
• Minor: Non-breaking schema changes - field or type addition
• Patch: No schema change, but the digest has changed - rest of the changes.

Future Improvements
One could also query using filters such as /graphql/^0.1.2, [find out more].(https://docs.npmjs.com/about-semantic-versioning)

Working
We will add a new cli feature tag which will allow developers to tag a version once published. It would work as follows —

1. The developer needs to publish the specification first

> tc publish ./jsonplaceholder.graphql

Deployment was completed successfully.
Digest:     b80aca49a8061f74d04245fdbf975b8b4565b232a257497c0e65d15ec7d97d77
Endpoints:  19
Unsafe:     0
Playground: https://cloud.tailcall.run/graphql/b80aca49a8061f74d04245fdbf975b8b4565b232a257497c0e65d15ec7d97d77.
N + 1:      19

👍 Completed in 1369 ms.

2. The developer will use a new command tag to tag the published schema. The --auto flag will infer a semantic tag and insert it.

> tc tag b80aca49a8061f74d04245fdbf975b8b4565b232a257497c0e65d15ec7d97d77 --auto

Deployment tagged successfully.
Digest: b80aca49a8061f74d04245fdbf975b8b4565b232a257497c0e65d15ec7d97d77
Endpoints:  19
Unsafe:     0
Playground: 
Tags:   v1.2.0
👍 Completed in 136 ms.

Note

• Tags should be unique, ie a tag used once, should not be used again.
• Tags can be dropped or assigned to another digest
• A digest can have more than one tag
• Querying digests by tag should be possible.

Currently its a lot of work to type out every field while implementing interfaces. This is something our compiler can do automatically. Fields that have not been implemented should be automatically copied from the interface.

• Versioning should follow 0.x.x until a stable 1.0.0 is released.
• Automatically update minor and patch versions with each commit.
• Auto-generate release notes
• Update documentation for how to download and install the released version.

Use graphql spec files to replace Config building logic in ConfigExecutionSpec (similar to ConfigPropertySpec)

Config.Server has support for specifying vars. Essentially global variables that can be used anywhere. This should be passed as context but isn't at the moment.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Edited/Blocked

These updates have been manually edited so Renovate will no longer make changes. To discard all commits and start over, click on a checkbox.

• fix(deps): update rust crate headers to 0.4.0
• chore(deps): update wandalen/wretry.action action to v3

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• fix(deps): update rust crate http-cache-reqwest to 0.14.0
• fix(deps): update rust crate hyper-rustls to 0.27.1
• fix(deps): update rust crate reqwest-middleware to 0.3.0
• Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• fix(deps): update rust crate rustls to 0.23.4
• fix(deps): update rust crate reqwest to 0.12
• fix(deps): update rust crate hyper to v1
• fix(deps): update rust crate rustls-pemfile to v2

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository