Add endpoints to support Cloud Code viewer in dashboard.

[drew-gross]

The server needs two additional endpoints to support viewing Cloud Code in the dashboard: the /releases/latest endpoint, and the /scripts endpoint. These should both be master key only. You can check the expected response by checking the response for an app that is on Parse.com. Some of the values won't make any sense such as _id, and timestamp, and some are difficult to understand, such as triggers. You can leave those ones out.

[flovilmart]

Pretty tough one indeed as we don't pass a cloud code folder but a single file with it's own deps...

[drew-gross]

Yeah that part could be difficult. This may require some change to how the server is configured (ie. pass a path to a folder).

[savirdev]

I'm not sure how to add an endpoint. You mean something like:

app.use('/scripts', express.static(path.join(__dirname, '/scripts')));

in the parse server?

[grassland-curing-cfa]

Any update on this?

[flovilmart]

Not for the moment

[krzkz94]

Could anyone post a example response from the two endpoints?

/releases/latest
and
/scripts

I would happily check by myself but i can't register on parse since they are not accepting new signups.

[itayAmza]

How do i add the two additional endpoints to the server?
Just add app.use in the index file?
Can you please explain more?

[ljs19923]

Somebody working on this feature actually ? :)

[xor22h]

Could anyone post a example response from the two endpoints?

/releases/latest

[
  {
    version: "v1112",
    apiKey: "********-****-4f5d-****-8679063ad2f2",
    _id: "Lvc5pMq3AI",
    parseVersion: "1.6.14",
    timestamp: "2016-07-29T13:55:53.881Z",
    triggers: { },
    checksums: "{\"cloud\":{\"app.js\":\"e0bd029a459d32beac67d490db35f2a6\",\"main.js\":\"2ae1ea152d3b0e27c577890fa8d2f2f6\",\"views/extra.ejs\":\"ae9c8593d530912d87d49adcb57dac21\",\"views/privacy.ejs\":\"26b76fc6a662d2ceaa8398480d242a40\",\"views/terms.ejs\":\"82d4740f759767c1bb5815dcc438f4b8\"},\"public\":{\"a.js\":\"be856b4277b318048eebae4fcdbbd0ee\",\"favicon.ico\":\"0dcddc7ae9c6f8827f52b85a856ff838\",\"font/Hind-Bold.eot\":\"f3d3e038c5b929a3fe58e1c68402516c\",\"font/Hind-Bold.ttf\":\"c0496aab20cb60d02394d7cbe76e8b09\",\"font/Hind-Bold.woff\":\"563458e9af7939f8e0bed8f10989b916\",\"font/Hind-Light.eot\":\"90534b111fcf42701f3e7fef7202df51\",\"font/Hind-Light.ttf\":\"90441962f79d8177682878ccb12baef0\",\"font/Hind-Light.woff\":\"37a556acb5b3fa01379881503eb4bbbd\",\"font/Hind-Medium.eot\":\"5e8cb1cd3cb8dab312da7decc35d9209\",\"font/Hind-Medium.ttf\":\"31fe3341b9c9027029baa444659214bf\",\"font/Hind-Medium.woff\":\"7a997fcbcb4ff6adf13339f2164c6777\",\"font/Hind-Regular.eot\":\"e1fc76d15e7242e30ac47e909f9264c3\",\"font/Hind-Regular.ttf\":\"143f6fcd29d7b002b9978b70387ab28a\",\"font/Hind-Regular.woff\":\"8b9e0bfc6efad1231e7b583ae5d0d50d\",\"font/Hind-Semibold.eot\":\"f7ea3be270db9e3083a588e1603f8e4b\",\"font/Hind-Semibold.ttf\":\"8a055aa43084c55f290d219c4d1d8d9e\",\"font/Hind-Semibold.woff\":\"c76a9e06b2e1b12a1389fdf68c3b41bf\",\"font/hind.css\":\"792f747bb52ebda8d47104a0d7a511b7\",\"img/appstore.png\":\"f9af1989b86cd12ce9f32b465220da2a\",\"img/bullet.png\":\"3841a890a819c28a4b9c0058da6e8cad\",\"img/iphone-A.png\":\"6f7c5121de92981372aedb2c22467f26\",\"img/iphone-B.png\":\"07bf3716a99268981bd389ff3be825ba\",\"img/iphone-C.png\":\"b8f87dc85beefc80fba0c3c012f234f2\",\"img/iphone.png\":\"7d26fee95f609f327143591ac595f6e2\",\"img/join.png\":\"4ec63cf1c4f0cfc797e0710c23563e2b\",\"img/logo-mail.png\":\"e643143080fd7449b81a2b19c682ac2e\",\"img/logo.png\":\"dceddf3f227de5cf759ea53b9e690f3f\",\"img/phone.jpg\":\"3ed52f996afc84dbde3f7f246b5df126\",\"img/playstore.png\":\"8b5a6202c9f6b3ecf59e5ca09cdceab6\",\"img/template-A.jpg\":\"638bcb875f9ce4cb80fae74c42a29f2d\",\"index.html\":\"4b158bf0fe13faa39ef84a6b67f11c02\",\"language.js\":\"d7e5030d86ab9956b0cc39abb4cb6f21\",\"octoly/index.html\":\"20e57c727c2f1eebad78285c6677c3b6\",\"octoly/logo.png\":\"b0eb9248148d58984d33895245257c63\",\"octoly/style.css\":\"e64cd2921533d26050101bdf1893eefc\",\"style.css\":\"3d1563a78dd3c05201580b7c4702df1e\"}}",
    userFiles: "{\"cloud\":{\"app.js\":\"2015-12-17T06:02:04.663Z\",\"main.js\":\"2016-07-29T13:55:53.695Z\",\"views/extra.ejs\":\"2015-12-16T03:51:04.026Z\",\"views/privacy.ejs\":\"2015-12-17T06:02:04.818Z\",\"views/terms.ejs\":\"2015-12-17T06:03:13.834Z\"},\"public\":{\"a.js\":\"2016-02-08T22:26:02.825Z\",\"favicon.ico\":\"2015-12-16T03:14:05.506Z\",\"font/Hind-Bold.eot\":\"2015-12-16T03:07:29.006Z\",\"font/Hind-Bold.ttf\":\"2015-12-16T03:07:42.612Z\",\"font/Hind-Bold.woff\":\"2015-12-16T03:07:09.143Z\",\"font/Hind-Light.eot\":\"2015-12-16T03:07:41.288Z\",\"font/Hind-Light.ttf\":\"2015-12-16T03:07:35.776Z\",\"font/Hind-Light.woff\":\"2015-12-16T03:07:10.735Z\",\"font/Hind-Medium.eot\":\"2015-12-16T03:07:40.599Z\",\"font/Hind-Medium.ttf\":\"2015-12-16T03:07:31.986Z\",\"font/Hind-Medium.woff\":\"2015-12-16T03:07:03.558Z\",\"font/Hind-Regular.eot\":\"2015-12-16T03:07:27.934Z\",\"font/Hind-Regular.ttf\":\"2015-12-16T03:07:29.313Z\",\"font/Hind-Regular.woff\":\"2015-12-16T03:07:36.853Z\",\"font/Hind-Semibold.eot\":\"2015-12-16T03:07:32.351Z\",\"font/Hind-Semibold.ttf\":\"2015-12-16T03:07:30.711Z\",\"font/Hind-Semibold.woff\":\"2015-12-16T03:07:05.109Z\",\"font/hind.css\":\"2015-12-16T03:06:47.209Z\",\"img/appstore.png\":\"2015-12-16T03:07:00.171Z\",\"img/bullet.png\":\"2015-12-16T03:06:51.690Z\",\"img/iphone-A.png\":\"2015-12-16T03:47:20.054Z\",\"img/iphone-B.png\":\"2015-12-16T03:47:15.151Z\",\"img/iphone-C.png\":\"2015-12-16T03:47:12.396Z\",\"img/iphone.png\":\"2015-12-16T03:07:15.586Z\",\"img/join.png\":\"2015-12-16T03:06:43.184Z\",\"img/logo-mail.png\":\"2015-12-16T03:06:58.076Z\",\"img/logo.png\":\"2015-12-16T03:14:05.682Z\",\"img/phone.jpg\":\"2015-12-16T03:07:30.196Z\",\"img/playstore.png\":\"2015-12-16T03:06:52.599Z\",\"img/template-A.jpg\":\"2015-12-16T03:07:13.347Z\",\"index.html\":\"2016-02-03T23:01:35.569Z\",\"language.js\":\"2015-12-16T03:06:56.805Z\",\"octoly/index.html\":\"2016-02-10T13:38:04.954Z\",\"octoly/logo.png\":\"2016-02-08T23:01:23.905Z\",\"octoly/style.css\":\"2016-02-10T13:38:05.516Z\",\"style.css\":\"2015-12-16T03:07:15.105Z\"}}"
  }
]

and scripts/filename seems to return file body as string.

"var express = require('express');\nvar app = express();\n\napp.set('views', 'cloud/views');\napp.set('view engine', 'ejs');\napp.use(express.bodyParser());\n\napp.get('/extra', function(req, res) {\n\tres.render('extra');\n});\n\napp.get('/privacy', function(req, res) {\n\tres.render('privacy');\n});\n\napp.get('/terms', function(req, res) {\n\tres.render('terms');\n});\n\napp.listen();\n"

[xor22h]

Is anyone actually working on this issue?

[flovilmart]

I am currently not, it's up for grabs.

[insthync]

Seems like we have to add new Cloud code endpoint to response the required data (That I whats are them exactly), I've tried in Sashido for releases/latest with GET and POST method it's return
[ { "triggers": {}, "checksums": "{\"public\":{\"css/main.css\":\"242fb343b773bb0d747ab7238b690097a2db32f9\",\"index.html\":\"3ba5608b342a5315b569773e6bb961141c8ab9e3\"},\"cloud\":{\"app.js\":\"424fe5638dcc044b5019119e7a79a005eb0ddd91\",\"functions.js\":\"f25b5be83bbd6a577fa402a3bd8ba14930e27562\",\"main.js\":\"f12b138b0219bfa1134c925134845b9a70bbb136\"}}", "userFiles": "{\"public\":{\"css/main.css\":\"version\",\"index.html\":\"version\"},\"cloud\":{\"app.js\":\"version\",\"functions.js\":\"version\",\"main.js\":\"version\"}}" } ]

For the scripts endpoint returning just OK

I have tried with
app.get(mountPath + '/releases/latest', function(req, res) { ... });
and
app.get(mountPath + '/scripts', function(req, res) { ... });

But still not works, still no cloud code section on dashboard

[dblythy]

Hey all,

I’ve worked on this PR that solves this issue, and also allows dependencies to be loaded in the cloud code viewer.

What do we think of this approach, and are there any additional features or changes that we’d like in the dashboard?

[mtrezza]

Could you give a conceptual description of how you solved this?

[dblythy]

So as Drew stated, all that is required is two endpoints:

• /releases/latest
• /scripts/file

And the Parse Dashboard can do the rest. But as flovimart mentioned:

Pretty tough one indeed as we don't pass a cloud code folder but a single file with it's own deps...

So, for the /releases/latest endpoint, my code starts off with the cloud code file specified (i.e main.js), and then attempts to load any additional dependancies that are called using require(). I've. written test cases for this and it seems to display nicely. Here's my server with the config cloud: 'main2.js': (main2.js imports files from /functions/)

The /scripts/file endpoint is just required to return the content of the requested file from Parse Dashboard.

I have also added another endpoint: POST /scripts/file, and changed the dashboard to allow editing of the cloud files via the dashboard.

[mtrezza]

Thanks @dblythy, which PRs (parse server, dashboard, JS SDK?) are required to try out this feature?

[dblythy]

This PR from Parse Dashboard, and a cloud code file.

[mtrezza]

attempts to load any additional dependancies that are called using require()

About about import statements? What happens if a file not required during development, will it then just disappear from the tree, even though it exists? If so, I'm not sure this is the right approach. It may be better to scan the directory and return the tree.

I have also added another endpoint: POST /scripts/file, and changed the dashboard to allow editing of the cloud files via the dashboard.

If editing an existing resource, it should be a PATCH endpoint. I assume the most practical would be a PUT endpoint, if you don't just transmit the diff of a file; that is equivalent to an upsert.

So as Drew stated, all that is required is two endpoints

That is only somewhat true, depending on the intended purpose of this feature. Any code changes made via dashboard are not sustained if the server re-deploys, because there is no persistent code management. Parse.com had this, as is apparent from example responses. In my understanding, the approach you described is only suitable for local development. But then again, for local development, one would rather use an IDE, which provides many benefits over developing via dashboard, just to name debugging as an example.

I think the first step would be to define the intended purpose of such a feature and for which developer audience that would be built. Let's also keep in mind that the dev landscape has evolved since 2016 when this issue was opened or when hosted Parse was popular. Part of the success of hosted Parse was the ease of accessibility, managing code without local IDE and repo management via CLI. Today, we have tools like Visual Studio Code and GitHub Desktop (which didn't exist back then) that make is much easier to develop code. Even beginning developers can start easily with these tools.

We should explore whether the feature of editing code via Parse Dashboard has become obsolete. We can always add features, but they should be purposeful and sustainable into the near future, because they come at a cost (code maintenance, new dependencies / vulnerabilities, etc.).

[dblythy]

I do agree, I think that Parse Server + VSCode + TypeScript is probably much more newbie friendly than including a cloud code editor as part of the dashboard. Especially considering VSCode supports npm scripts, terminal windows, git, debugging, etc.

I would assume the use for viewing cloud code files would be to try to identify bugs in the code on a production server. However, I personally think this could be improved by adding either a blog post or CI in the example for to deploy a private repo via CI on changes, and code viewing be left to GitHub. It would be good to understand why there is a demand for this feature, as I wouldn't personally use it.

[mtrezza]

I would assume the use for viewing cloud code files would be to try to identify bugs in the code on a production server.

How so? Identifying bugs on a production server (I assume you mean a remote deployment), is done via logs. The code itself should be available for viewing (and debugging) in a local dev environment, just on a different branch.

I personally think this could be improved by adding either a blog post or CI in the example for to deploy a private repo via CI on changes, and code viewing be left to GitHub.

There are many different CI pipeline concepts out there, each cloud provider has their own approach. Some may auto-deploy from a repo on commit, others may upload manually via CLI. I am not sure a pipeline is something Parse Server should cover beyond maybe an anecdotal blog post. But even then we would need to make sure the pipeline makes sense. Suggesting to use GitHub for code viewing maybe your personal pipeline, but it sounds a bit odd to me and it'd probably not be something we'd recommend in a blog.

It would be good to understand why there is a demand for this feature, as I wouldn't personally use it.

I wasn't aware that where was any demand. Is there any? This issue is open since 2016 and was dormant for 5 years it seems until you opened the PR 🙂

I still think if we can find a roadmap for this feature your PR could be a first step to build upon, but I don't see a possible roadmap yet that makes this feature sustainable in a code pipeline. Maybe if Parse Server has the ability to push changes done via the Dashboard to a repo, and that is easily configurable, that could be part of a roadmap? The issue however is that pipelines usually work the other way around, the code is pushed to a repo which then triggers a new deploy, not the other way around.

Bottom line is, we are developing a somewhat dysfunctional IDE in Parse Dashboard which I think is a fruitless exercise because we will never be able to compete with the functionality of a local IDE. For the same reason, we are not building a Parse Server Analytics module, there are open source and commercial solutions that we would not be able to compete with.

[dblythy]

Really good points. It seems as this was initially demanded as most people weren't clear how to use Parse Server with an IDE, or were editing cloud code via terminal. With how far we've come, I do agree that adding this is almost a backwards step, especially with incoming TypeScript support.

[mtrezza]

How do you suggest to proceed with this issue and related PRs?

[dblythy]

I close this and the PRs as a wontfix issue, unless someone can explain why in 2021 this feature is relevant.

[mtrezza]

Sounds good. There have been some users recently asking when this feature becomes available. Maybe you want to explicitly link to this thread when closing, so people can join the discussion here if they want to argue why the feature should be added.

I am closing this because the feature seems outdated and strategically obsolete as outlined here and here.