Prisma1: Go client: Environment variable interpolation

[divyenduz]

Describe the bug
Current implementation of environment interpolation in Prisma client relies on tagged template literals which only works for Javascript.

This is currently a bug in Go client and would be a bug in all languages where we interpolate variables like this.

To Reproduce
Steps to reproduce the behavior:

1. Generate a Go client with environment variables
2. Try to use the client

Expected behavior
The generation should implement either a language agnostic or language specific interpolation method. Here are the proposed approaches:-

1. Language agnostic - Domain-specific language (DSL)

We can create a small domain specific template strategy that can be shared by all the programming languages. The language specific client runtime can parse the template and create a URL that supports environment variables.

For e.g. the client can emit the following (basically copying prisma.yml as is in places of doing JS interpolation it does currently):-
"http://{env:SERVER_URL}/{env:STAGE}"

And then this is translated into language specific URL strings by the language specific client runtimes:-

1. JS

`http://{process.env.SERVER_URL}/${process.env.STAGE}`

1. Go lang
   "http://" + os.Getenv("SERVER_URL") + "/" + os.Getenv("STAGE")

2. php
   "http://" . $_ENV["SERVER_URL"] . "/" . $_ENV["STAGE"]

2. Language specific

While generation, we can generate language specific strings, the output for the following string in prisma.yml (http://{env:SERVER_URL}/{env:STAGE}) would be the following at generate time:-

1. JS

`http://{process.env.SERVER_URL}/${process.env.STAGE}`

1. Go lang
   "http://" + os.Getenv("SERVER_URL") + "/" + os.Getenv("STAGE")

2. php
   "http://" . $_ENV["SERVER_URL"] . "/" . $_ENV["STAGE"]

The 2nd approach sounds more idiomatic and more language specific (as the generation should be) but the advantage of 1st approach is that we can pre-process environment variables if needed via updating the runtime without change in generated code.

Personally, I favor approach 2 because it is less magical for end user :)

Versions (please complete the following information):

• prisma CLI: [e.g. prisma/1.18.0 (darwin-x64) node-v10.4.0]

[schickling]

The language specific implementation (proposal 2) is the way to go. Let's get this implemented 💪

[mbenaiss]

This issue is not totally resolved:

If we generate Goclient with an environment variable : PRISMA_ENDPOINT=http://localhost:4466

we got

var DefaultEndpoint = "`os.Getenv("PRISMA_ENDPOINT")`"

but we expect

var DefaultEndpoint = os.Getenv("PRISMA_ENDPOINT")

Prisma CLI version : prisma/1.25.0 (darwin-x64) node-v11.3.0
Go version : go version go1.11 darwin/amd64

[dominikh]

@divyenduz See @mbenaiss's comment. Should this issue be reopened?

[divyenduz]

@dominikh, @mbenaiss : Even this one is fixed in the latest version (1.27.x) of Prisma CLI via https://github.com/prisma/prisma/pull/3915

Please install it via npm install -g prisma and let me know if the problem persists.

[mbenaiss]

@dominikh, @divyenduz: 👋yes I confirm that this problem has been fixed Thanks 👍