Comments (10)
I am not sure that "provide credentials with env vars" matches the mongo model. They authenticate (at least partially) using trusted IP addresses. I assume in that the requests to mongo will come from our actions and so I think the "trusted ip address" would have to be something that our backend would use. But, of course, this would not be individualized.
They do have a concept of "database users" on top of this, and perhaps we can individualize that way, in which case some creds would again be part of the env vars. But ....
I'm currently using a free tier mongo (deployed in GCP). I think even if I figure out what IP address would be originating the requests on nimgcp
we would not want to use that unless we can add another layer of authentication that would keep absolutely any action from using the instance.
More generally, if this becomes a useful demo and users want to deploy it with their own mongo instances, I don't see how that would work. Do we publish the originating IP address? Is that even a stable piece of information?
from demo-projects.
I decided to set aside mongoDb issues for now and focus on porting the code. If I'm lucky I'll get something that works except for DB access and then someone can help me figure out the DB access. The code is available in https://github.com/willvelida/serverless-mongodb-api.
The service appears to be (in our terms) a package with five actions. The actions share some model code (modest amount). The build for Azure looks like it makes a single executable with all five actions (I know so little about .net that I'm not completely sure).
The signature of each action will have to be changed to fit the conventions dictated by the OW .net runtime (this uses a third-party package NewtonSoft.JSON). Then, the question will be whether it pays to try to break up the code or just run the build five times and declare different Mains. Obviously, the latter is inefficient but I know we've resorted to that at times (e.g. with lambda ports).
from demo-projects.
PR #44 represents progress to date. Not mergeable yet because the actions don't initialize correctly (I don't know why yet). The approach I followed was to include only one of the original Azure functions in each action but to copy other material (the csproj
file and the models
code) from a common place.
So far I have ported two actions, GetAlbum
and CreateAlbum
. If those two work, the other three should be easy to add.
I was hoping to get where the actions could be invoked but would simply fail on the database access. There are three environment parameters MONGO_CONNECTION_STRING, DATABASE_NAME, COLLECTION_NAME which need to be filled in for the database access to work and I'm not sure I created the Mongo instance correctly for the exercise.
But, in any case, the actions don't get that far yet. I am getting a failure to initialize with this activation record:
{
"activationId": "67160e5054da40ce960e5054da80cea4",
"annotations": [
{
"key": "path",
"value": "wbtestni-grinjpsjnuh/mongo-music/GetAlbum"
},
{
"key": "waitTime",
"value": 652
},
{
"key": "entry",
"value": "MongoMusic.API::MongoMusic.API.GetAlbum::Main"
},
{
"key": "kind",
"value": "dotnet:3.1"
},
{
"key": "timeout",
"value": false
},
{
"key": "limits",
"value": {
"concurrency": 1,
"logs": 16,
"memory": 256,
"timeout": 3000
}
},
{
"key": "initTime",
"value": 593
}
],
"duration": 593,
"end": 1607987704231,
"logs": [
"2020-12-14T23:15:04.232294Z stderr: The action did not initialize or run as expected. Log data might be missing."
],
"name": "GetAlbum",
"namespace": "wbtestni-grinjpsjnuh",
"publish": false,
"response": {
"result": {
"error": "Unable to decompress package."
},
"size": 41,
"status": "action developer error",
"success": false
},
"start": 1607987703638,
"subject": "[email protected]",
"version": "0.0.1",
"date": "2020-12-14 18:15:03"
}
from demo-projects.
"result": { "error": "Unable to decompress package." },
This comes from the following code in the dotnet runtime:
try
{
System.IO.Compression.ZipFile.ExtractToDirectory(tempFile, tempPath);
}
catch (Exception)
{
await httpContext.Response.WriteError("Unable to decompress package.");
return (null);
}
So, it is apparently unhappy with the format of the zip file produced by the deployer's autowrap feature. Curious, since the older example (hello-dotnet
) also uses that feature but the zip file is accepted in that case.
In the Apache quickstart, they show the file being zipped with -0 ("store only"), that is, with no compression. The deployer autowrap will zip with whatever the default compression is for archiver('zip'). There is an option to suppress compression but we don't use it currently. Things to try next
- try using the 'store' flag in the deployer. Then consider whether this change is the new default, or to be turned on optionally with a command line flag
- stop using autozip in this example (and, for the moment, discourage its use with the dotnet runtime)
Will experiment down those lines.
from demo-projects.
I wasn't, on first try, able to change the behavior of the autozipper, so I will leave that for another day. I changed the action builds to use zip -0
(make the zip file manually in the build script). That got past the initial problem. Next: it's not accepting my main
so investigating that.
from demo-projects.
The problem with main
was trivial (namespace mismatch). Then things began to work, although for a while I was confused by the fact that the dotnet runtime is especially nasty about actions that leak exceptions. They don't report the exception and make it look like an initialization error. I finally realized initialization was working and I was making an error in a catch block that caused a second exception.
Now the two actions I have are "sorta kinda" working without mongo. I can't really tell whether they do the right thing in all respects until we have mongo hooked up.
from demo-projects.
This example now works and the PR that adds it has been merged. More work can be done here but is deferred for the moment.
- The README should be updated to show invocation via URL using
curl
, more similar to how the actions would be used when considered as an API - Once the newest
.NET
runtime is in production, supporting "environment parameters", the example should change to segregate "system" parameters in the environment so that the input JObject has only user-specified parameters - Test scaffolding should be added so that the logic of the actions can be tested locally
- The existing two actions should be refactored so that common initialization code is segregated in a separate class and not duplicated
- The remaining three actions from the original code should be translated
from demo-projects.
For reference - not more sophisticated but this setup works with Visual Studio https://github.com/rabbah/hello.net.
from demo-projects.
After discussion with @bhageena , who has dotnet experience, I'm transferring this issue to him.
from demo-projects.
Closing because this is way below the radar for available developers at the moment.
Could be reopened if new motivations appear to raise the priority.
from demo-projects.
Related Issues (20)
- Add example how to use the Nimbella election API instead without civic api key HOT 1
- Add manual simulation mode for electoral map HOT 1
- Add Jest unit tests for API functions HOT 3
- Move initializer to init time HOT 1
- Add Jest unit test for News API HOT 1
- allow election project to work without civic api key HOT 1
- election app loads invalid urls HOT 1
- when using division and voter pages you have to click the search icon HOT 1
- election API docs should clarify what base url means HOT 1
- qr and qr-java should not be combined in one project HOT 1
- Very confusing (and wrong) file upload option HOT 2
- Election demo web build started breaking due to dependency change HOT 4
- Set up GitHub actions to build the demos.
- chore: configure/enable dependabot HOT 1
- add typescript example HOT 1
- add react starter that requires no api key/configuration
- Replace require('nim') calls with updated sdk
- page visits deploy broken HOT 1
- add auth0 project demo
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from demo-projects.