Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Endpoints to view and edit Cloud Functions in dashboard #6983

Closed
wants to merge 11 commits into from

Conversation

dblythy
Copy link
Member

@dblythy dblythy commented Nov 1, 2020

This PR closes the oldest issue here #895, and allows developers to see their cloud endpoints in the dashboard. Also related to 81, 532, #6752.

A small update to the Dashboard will be required.

This also attempts to find dependancies from the entry point, so that configurations with one cloud file that imports other files via require(), still show in the dashboard.

In my config, my main entry point is main2.js, with the content:

require('./functions/_User.js');
require('./functions/2FA.js');
require("./functions/Admin.js");

Here's how that looks in the dashboard with the PR:

Screen Shot 2020-11-02 at 2 53 48 am

And clicking on each of those links opens the file as:

Screen Shot 2020-11-02 at 2 53 57 am

Let me know what you think!

@codecov
Copy link

codecov bot commented Nov 1, 2020

Codecov Report

Merging #6983 (1db9c75) into master (08b2ea4) will decrease coverage by 0.00%.
The diff coverage is 94.54%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #6983      +/-   ##
==========================================
- Coverage   93.93%   93.92%   -0.01%     
==========================================
  Files         169      169              
  Lines       12547    12602      +55     
==========================================
+ Hits        11786    11837      +51     
- Misses        761      765       +4     
Impacted Files Coverage Δ
src/Options/index.js 100.00% <ø> (ø)
src/Routers/FeaturesRouter.js 100.00% <ø> (ø)
src/Routers/CloudCodeRouter.js 96.59% <94.44%> (-3.41%) ⬇️
src/Options/Definitions.js 100.00% <100.00%> (ø)
src/Adapters/Files/GridFSBucketAdapter.js 79.50% <0.00%> (-0.82%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 08b2ea4...1db9c75. Read the comment docs.

@mtrezza
Copy link
Member

mtrezza commented Nov 1, 2020

This is another great feature addition.

Considering that this feature is rather extensive and involves multiple PRs / repos, could you please open an issue in which we can have a meta discussion about the approach? The benefit of meta discussions in issues rather than PRs is they usually enjoy better visibility which leads to a more engaged discussion, especially when members of existing threads are re-engaged. Alternatively, you could pick up an existing issue thread which seems most recent / appropriate.

Even though we have the luxury that you already provided the complete PR (👏), a proper meta discussion provides a structured approach to introduce and evaluate this feature.

@dblythy
Copy link
Member Author

dblythy commented Nov 1, 2020

Considering that this feature involves multiple PRs / repos, could you please open an issue in which we can have a meta discussion about the approach?

No worries. I can do that. Would you rather a new issue or continue the discussion of the existing issue? Sorry for diving into these PRs without discussing first. It pains my OCD to see 86 open issues with many being "up for grabs" for 4+ years.

@mtrezza
Copy link
Member

mtrezza commented Nov 1, 2020

Would you rather a new issue or continue the discussion of the existing issue?

Maybe you want to use the existing issue #895 as it already references related issues and doesn't already have a long discussion that for example goes about a completely different approach.

It pains my OCD to see 86 open issues with many being "up for grabs" for 4+ years.

I can assure you that your recent PRs and feature introductions are very appreciated by the community. Practically, it is most important that there is an actual PR to discuss, which you even provide as the first step, so your ambitious approach is much appreciated. 🙂

@dblythy
Copy link
Member Author

dblythy commented Nov 2, 2020

I have also added another endpoint that allows writing cloud files, which I think is pretty cool.

The inbuilt code editor in the dashboard decent, so I thought why not utilise it.

Although I'm pretty sure editing cloud files will still require a restart of the server? Maybe we could look at building that in.

I'm also not a react or web developer so UI might need some work.

Screen Shot 2020-11-02 at 2 11 09 pm

@dblythy dblythy changed the title Add Endpoints to view Cloud Functions in dashboard Add Endpoints to view and edit Cloud Functions in dashboard Nov 2, 2020
Copy link
Member

@Moumouls Moumouls left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that the implementation do not support multi parse server deployment, so this can result in huge inconsistency issue in prod environment ? Otherwise in local dev env the implementation looks good.

May be the way to support multi parse server deployment is to save a string version of the cloud function and then perform an equality check. Then before running the cloud function we need to perform a request to ensure that the latest version is loaded.

src/Routers/CloudCodeRouter.js Show resolved Hide resolved
@dblythy
Copy link
Member Author

dblythy commented Dec 15, 2020

Good point and thanks for the review @Moumouls. I’m not sure how this handles multiple servers to be honest, most of the related code was already there, I just made the endpoints available. I’ll have a look at multi-server.

A problem with the editing feature is also that the server will need to restart for changes to take affect.

@Moumouls
Copy link
Member

Moumouls commented Dec 15, 2020

@dblythy i just pass this PR to draft since it needs some adjustments before getting everything working perfectly !

For restart may be you can try something like listed here: nodejs/help#923

@Moumouls Moumouls closed this Dec 15, 2020
@Moumouls Moumouls reopened this Dec 15, 2020
@Moumouls Moumouls marked this pull request as draft December 15, 2020 17:39
@ghost
Copy link

ghost commented Feb 4, 2021

Danger run resulted in 1 warning; to find out more, see the checks page.

Generated by 🚫 dangerJS

@dblythy dblythy marked this pull request as ready for review February 4, 2021 07:55
@dblythy
Copy link
Member Author

dblythy commented Feb 4, 2021

@Moumouls I have added the following server parameters:

dashboardOptions: {
        cloudFileView: true, // fine to use on multi-instance
        cloudFileEdit: true, // local / single instance only
}

If this approach is ok, I will update the dashboard PR so that it only allows editing if cloudFileEdit is true.

@dblythy
Copy link
Member Author

dblythy commented Mar 3, 2021

@mtrezza do we have any appetite for having this for the next Parse Server version (even if we strip out cloudFileEdit for now?). It would be good to be able to work it in with a dashboard release too.

@mtrezza
Copy link
Member

mtrezza commented Mar 3, 2021

Sure! I'm all for it, the sooner features are released, the sooner we get feedback for them.

@kaanselhep
Copy link

Looks like the 2 warnings that appear are for writing tests for the lines such as:
throw new Parse.Error(Parse.Error.INTERNAL_SERVER_ERROR, 'No data to save.');

@DiegoBM
Copy link

DiegoBM commented May 18, 2021

When should we expect this to be merged on the main branch, if there is any ETA?

@dblythy
Copy link
Member Author

dblythy commented May 19, 2021

When should we expect this to be merged on the main branch, if there is any ETA?

It's up to the core team 😊

@Moumouls
Copy link
Member

Moumouls commented May 19, 2021

@dblythy here just about the multi server support, did you add some code or some warning somewhere on the dashboard. A new developer could not understand why his app in node cluster could fall into inconsistent state (outdated code on other instances).

Also here we need an another warning/block API if parse is used into a docker image (if i remember with process.env we can detect if parse run into a Docker container), why ? because if the container is restarted and the container do not have some volume mapped ALL MODIFICATIONS will be LOST.

May be you can add some documentation about limitations on the config js, then some automatic JS doc will be generated 👍

This is a nice feature (low code developers will love it) but we need to ensure that a developer know risks about using it.

(sorry for my late comment 🙂 )

@mtrezza
Copy link
Member

mtrezza commented May 19, 2021

When should we expect this to be merged on the main branch, if there is any ETA?

It's up to the core team 😊

@dblythy From that I assume the PR is ready for review. I have added some conceptual notes to the high level discussion that we should look into. The conclusions there may require adjustments in this PR or even make the feature itself obsolete.

Anyone who is waiting for this feature to become available, please feel free to join the discussion in #895. It would be interesting to hear why this feature is even desired over using the usual IDE toolset.

@dblythy dblythy closed this May 27, 2021
@dblythy
Copy link
Member Author

dblythy commented May 27, 2021

After a discussion between @mtrezza and I, we have agreed that cloud file viewing and editing isn't necessary with Parse Server, and encourages bad practices. Here's why:

Before with parse.com, the only way you could manage your Parse Cloud was through Parse.com's dashboard. However, as you need to run a clone of the Parse Server Example repo to use Parse Server, having the cloud file editing via the dashboard is reinventing the wheel. We want users to become familiar with industry standard IDE's, and we'd never be able to keep the dashboard's IDE to the same standard. Plus, editing cloud code on a live server without running CI checks isn't good practices.

If you have comments or suggestions for why you'd want this feature, please comment at #895. If you need any tips as to how to set up a CI/CD pipeline, please join the discussion.

@Moumouls
Copy link
Member

yes @dblythy this feature was a little bit touchy, and also could push some developers in wrong direction, since this feature could sugges to bypass a standard CI/CD development pattern.

From the beginning, i was not really comfortable with the cloud edition approach.

From my side i would like to say sorry may be for your precious time wasted here. I should have expressed my reservations earlier.

@mtrezza
Copy link
Member

mtrezza commented May 27, 2021

From my side i would like to say sorry may be for your precious time wasted here.

As general note, I would just like to highlight this as another example why high-level discussions in issues (rather than mixed-level discussions in PRs) are the way to go. Especially when a feature has already been developed and it seems straightforward to just submit a PR, it is in the contributors own interests to initiate a high-level discussion to receive feedback about general viability - separately from the low-level feedback about a specific implementation in a PR. This is already reflected in the PR template, but we could make sure to explicitly mention this in our contribution guide.

@DiegoBM
Copy link

DiegoBM commented Jun 2, 2021

May I ask what will be the purpose of the functions panel in the future then? Or is it meant to be removed?

Could anyone please describe what would be the ideal flow/process to deploy functions to Parse? Or point to a link where that is explained? Some sort of tutorial would come handy. Thank you in advance

@mtrezza
Copy link
Member

mtrezza commented Jun 2, 2021

May I ask what will be the purpose of the functions panel in the future then? Or is it meant to be removed?

I don't think there is a "Functions" panel currently visible in the dashboard. The dashboard code still may contain artifacts of previous functionality here and there.

Could anyone please describe what would be the ideal flow/process to deploy functions to Parse? Or point to a link where that is explained?

"Ideal" depends on what works for you. You can do an online search for "continuous deployment" to find sophisticated examples of efficient code deployment. There is nothing specific about Parse Server when it comes to deployment pipeline. For general help with your deployment pipeline I suggest you ask for help in DevOps SE or the Parse Community Forum.

@DanielRub
Copy link

I think it should work the same way as AWS lambda functions. :

  • changes should be taken into account without reloading the server,
  • Any bug introduced in a cloud function should not affect the overall system. It should only affect the function itself.
  • Before saving changes, some checks can be applied for the user to get some visibilty on abvious bugs.

Just Trying to put myself in the user shoes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants