Is there a way to customize the `sst.ApolloApi` to...
# help
d
Is there a way to customize the
sst.ApolloApi
to use a custom path? We’d like the root method to be at
/api
This is so that we can put the api behind a Cloundfront Distro as a reverse proxy at
<http://mydomain.com/api|mydomain.com/api>
CF origins seem to always pass the path from the front end, so there is no way to have it be
/api
on the distro and
/
behind the scenes. (at least without a cloudfront function) Annoying I know.
@thdxr perhaps
sst.ApolloApi
needs a
rootRoute
property? I am curious what ApolloApi really gives you over just using
sst.Api
. Going to look at construct
ya looks like it’s mainly to make it quicker to setup a get and post pointing to a single function. I think this could still be done with a
rootRoute
no?
routeRoute: /api
(default:
/
) …
Copy code
routes: {
        `GET ${routeRoute}`: server,
        `POST ${routeRoute}`: server,
      },
t
Yeah you can use the standard sst.Api - personally use AppSync myself as I'm not a big fan of apollo
I'm not super familiar with our ApolloApi construct one second
d
I’m about to PR it to include an optional
rootRoute
as above
I don’t think we can use AppSync as we’re doing some advanced Schema stitching using graphql-tools. But we’re just learning it now, so not entirely sure this can’t be done in AppSync. Also, I’d rather use
sst.ApolloApi
if its less code 🙂
@thdxr thoughts?
t
Probably will let @Frank chime in since he made the original construct
d
what would be even better… is a
Reroute
construct that would implement a CF Function to do nothing more but reroute
from
to
by attaching a FunctionAssociation to a behavior. eg…
Copy code
new Reroute(this, {
  behavior,
  from: '/api/*',
  to: '/*'
})
🙂
then you wouldn’t need this change.
hmmm may try this. ☝️
f
Hey @Dan Van Brunt, having a
rootRoute
option makes sense. I might call it just
route
.
I will take a look at the issue today.
Reroute
is interesting idea too.. but having a
route
option seems more straight forward in this case.
d
@Frank understood. just didn’t want
route
to be confused with
sst.Api
’s
routes
as
route
would only be the string route and not the method or anything else.
I’ll see what I can get in.
f
Thanks @Dan Van Brunt! Ur suggestion on the naming makes a lot of sense. Between
rootRoute
and
rootPath
, which do u prefer? I lean towards
rootPath
more.
d
yup… rootPath makes sense
want me to adjust?
f
That’d be awesome!
Thanks @Dan Van Brunt Will get this merged asap.