packages/api/README.md
Redwood believes the future is serverless and multi-client. And @redwoodjs/api makes Redwood serverless and multi-client ready. Redwood has one API to rule them all. Your API is abstracted away from any one side of your application, so you can have as many sides as you need, and when you need them.
Right now, the @redwoodjs/api package exposes functions that help with logging, services, data fetching via Prisma, webhooks and authentication.
We also plan to make Functions platform-agnostic. At the moment, we're targeting AWS Lambda, but we aim to provide a single interface for other providers and build-time support when you've targeted them.
RedwoodJS provides an opinionated logger with sensible, practical defaults that grants you visibility into the JAMStack applications you're developing and have deployed -- with ease.
Logging in the serverless ecosystem is not trivial and neither is its configuration.
When choosing a Node.js logger to add to the framework, RedwoodJS required that it:
options) and where to log -- file, stdout, or remote transport stream -- (its destination)With those criteria in mind, Redwood includes pino with its rich features, ecosystem and community.
Plus ... pino means 🌲 pine tree! How perfect is that for RedwoodJS?
Note: RedwoodJS logging is setup for its api side only. For browser and web side error reporting or exception handling, these features will be addressed in a future release.
For detailed logger configuration, see the RedwoodJS logger package README.
@redwoodjs/api uses a few things you should be familiar with:
Although this package depends, in the code-dependency sense, only on @redwoodjs/internal, it still hangs together with the others—notably, @redwoodjs/web and @redwoodjs/api-server. So, if you’re asking yourself “but when does my server run?” head over to @redwoodjs/api-server.
If you’re asking yourself “but where is my GraphQL Server” head over to @redwoodjs/graphql-server.