Apex Code Development You need to sign in to do that
Don't have an account?
ollie123 Is Apex development a slow process for you?
I have recruited a developer to implement Apex-based functionality on a Salesforce.com instance, and my experience so far is that although the creation of objects/fields/validation/reports/search is VERY fast compared to the likes of ASP.NET, when it comes to creating Visualforce pages and add-on functionality not supported by the primary platform it is very slow.
As an example, recently my dev quoted several times the amount of time required to implement a specific feature than I know would be required to implement it in an ASP.NET app. He put this down to the cloud-based environment (yes, he's using Eclipse) and the fact that it's necessary to continually upload the code with all the tests on a regular basis.
It's a small app so we're not using the sandbox, instead deploying direct to production, the reasoning for that is the risks of this are quite tolerable, and overall it saves time.
I'm interested to hear if others generally find Apex development to be slower than other platforms.
Hi ollie123,
The short answer is: 'it depends'. If you are using a visualforce page (and its corresponding controller) with webservice callouts, it could be slow depending on your network speed, efficiency of the actual webservice, and the number of records processed.
If it does not do any webservice callout, then it could be slow because it is processing thousands of records using SOQL. Developing application on Force.com platform is quite different from developing application on Java, or .NET purely because Salesforce.com has gazillion restrictions on a code to run satisfactorily in their cloud. You have to be very creative to overcome, or satisfy the governer limits. IMHO, the testing requirement is too strict, and should be a bit lax.
In light of above arguments, if your code isn't SOQL intensive, or isn't making any webservice callouts, then it should run as fast as a standard Salesforce functionality/app.
Another advice or rather best practice followed by Force.com developers is that you should ALWAYS develop your code in sandbox, and then deploy your code to production even if the 'risks are quite tolerable'. The main argument behind this is that if the functionality/app breaks down, it is easy debug, and test it in sandbox than in production. You can play and tinker to your hearts content in the sandbox, but you can't do so in Production instance.
- AJ
in my experience, it takes more time to develop apps or add functionality on Force.com platform if you are new to cloud computing, and aren't familiar with Apex or Visualforce.
But if you spend a month or two with Apex and Visualforce and gain more experience, your dev time ideally should be reduced drastically. Please keep in mind that I speak from personal experience, and it is not based on any concrete statistics or survey. I've seen my co-developers struggle with the Force.com platform initially, but after 3-4 months of experience, they can now write a non-trivial business process in 2-3 days.
Cheers,
A J
Sure, I appreciate it will take people time to get up to speed, but it does seem that even after that initial ramp-up, developing on the force platform is significantly slower than platforms like ASP.NET where you can develop locally and very rapidly.
When I look at work I've done in the past with ASP.NET and compare the time it took, to similar development work on the force platform, my experience so far is that is is much slower.
Hi smuggles,
I think ollie isn't concerned about performance, he is more concerned about the actual 'dev' time on Force.com platform. He believes that development on the Force.com platform takes more time than developing similar app/functionality in .NET.
- AJ
If you don't want use the sandbox, surely he could be developing in his own free dev org to avoid having to redeploy every change to apex code through eclispe (slow) and avoid the need to keep up 75% test coverage during development? Oh and my eclipse never saves password/token after deploying, so you have to copy paste that **bleep** token every time.. that gets old fast.(Maybe I misunderstood something here)
On that topic, I don't think it's possible for the deployment process to be any more painful than it currently is. I particularly love when the deployment plan verifies fine, but after waiting 10 minutes on a big deployment you get back one field error.
The IDE really needs a lot of improvement. That's one of my biggest pain points as a new Force.com dev.
I think cpeterson has summed it all . I agree with the fact that salesforce provides a very nice framework to accomplish a lot of what we need in our business process ( relationships , reports , dashboard , sharing/security etc ) which would need a lot of time if we try to build it from scratch in .NET .
However , when you need to implement something that is not already in there , and need to deploy the code to salesforce , the process is very time consuming . Development process is always iterative , you write code , test it , see issues and then make changes . In sales force , its easy to write code in the offline mode of the eclipse IDE . However once you need to test it , you have to upload your changes to the server , which in my opinion is what slows the entire process down as even to make a small tweak you have to deploy again .
It would be great , if we could have a local sandbox setup where we could test these changes , and once finalized upload them to the server .
I know what you mean about the token. We finally went in to Setup>Administration Setup>Security Controls>Network Access and granted access to our IP address range. I don't have to enter the security token every time I want to deploy to production anymore...just the password.