Hello,
First I just want to say how grateful we are to have a fully fleshed out example like the Guild Service to look at and work with when getting up and running with Extend. I’m sure it will come in handy over and over later as we dive deeper.
However, seeing as how there are so many moving parts and opportunities for friction in developing an Extend service function I’d like to request that the Extend team offer another example project more in the vein of a Hello World. The reason for this is we are still struggling weeks later to get our first Extend function up and running. (I should clarify that when I say weeks, we’re only able to dedicate an hour or 2 per day to the project.) Personally I feel like the following is a great example of a Hello World: Get started with the Extend SDK | AccelByte Documentation …and so we’d just need a little more on top of it to get going. Is gRPC required or can we just go REST and bypass proto definitions? If gRPC is indeed required, is the gRPC gateway required? Loki? Telemetry / tracing? A simplified example that removes anything that could add avenues for friction and/or failures / more forum posts / loss in confidence would be immensely helpful. Looking forward to hearing your thoughts.
Thanks!
1 Like
Hi @njupshot
I’m one of the Extend team members.
Can you share what are you struggling with? This will be helpful for us to understand the gap.
Hey @vincentab, there are multiple ongoing threads in the forums with some of my colleagues. I’m running into the same challenges they initially faced, but we are getting shorter on time. What I’d rather do is start with a very simplified example that I can get up and running end to end quickly, then fully flesh it out over time. In other words, a hello world example to get going and build confidence then incrementally extend over time as development continues. For example, do you not agree that a dependency on GoLang and gRPC Gateway adds more moving parts / complexity and opportunity for friction? It may be that these things are just a requirement of the service right now which is all well and fine, but if they aren’t required I’m hoping to reduce complexity in an attempt to get up and running as quickly as possible.
1 Like
Hi @njupshot ,
We hear you about the need for a simpler starting point. We’re committed to providing resources and guidance to help you navigate through the initial setup and configuration. Understanding the specific struggles you’re encountering will allow us to tailor our support to your needs better. Could you elaborate further on the challenges you’re facing? This will help us provide more targeted assistance and streamline your experience with Extend.
Regarding GoLang and gRPC Gateway, they’re integral components of Extend for several reasons. Firstly, they help maintain compatibility both forward and backward, ensuring smooth transitions with future updates. Secondly, they make Extend language agnostic, enabling seamless integration with various programming languages. While they may introduce some initial complexity, they ultimately contribute to the robustness and flexibility of the service.
Looking forward to hearing from you and assisting you further.
OK thank you for the timely response Vincent. Here are a couple of the issues I’m currently facing:
(Note that we’re on Starter)
I’ve used getusertoken.sh to generate a token and am passing it via the Swagger UI and getting unauthorized:
…here’s the IAM permissions:
Hi @njupshot ,
I notice you don’t put a “Bearer” in front of the token. The expected authorization header format is “Bearer ”. Can you try again and see whether you can get past the issue? If this doesn’t work, I may need you to provide step-by-step instructions on how to reproduce the issue.
I would like to also understand what’re you trying to implement so I can recommend the right approach. Can you share the use case that led you to generate a user token via getusertoken.sh?
As a use case I’m just trying to get the Guild Service example working. Perhaps I’m just confused as to what token is expected here. When testing the API through swagger using the authenticated path, what kind of token is it expecting? How would I generate it?
Hi @njupshot,
When testing the API through swagger using the authenticated path, what kind of token is it expecting?
The token that it is expecting is an access token from AGS IAM service. For the current Extend Service Extension sample app (guildService), it is expecting access token with Cloud Save -> Game Records (Create, Read, Update, Delete) permissions.
How would I generate it?
The steps to get access token from AGS IAM service can be seen inside getusertoken.sh. But basically, the shell script calls the following endpoints.
- /iam/v3/oauth/authorize
- /iam/v3/authenticate
- /iam/v3/oauth/token
The access token will look similar to this: eyJhbGciOiJSUzI1NiIsImtpZCI6IjdiMmE2NzEyYTZmNjQwMzEyYTlkODAzNjk1ZDdlNmNl......
You can use the access token in the Swagger UI like the following.
